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Foreword 


T his background paper was prepared as part of the Office of Tech¬ 
nology Assessment’s follow-on assistance to the Senate Com¬ 
mittee on Governmental Affairs, subsequent to release of the 
September 1994 OTA report Information Security and Privacy in 
Network Environments. The Committee requested additional informa¬ 
tional and analytical assistance from OTA in order to prepare for hear¬ 
ings and legislation in the 104th Congress. 

This background paper updates and develops some key issues that 
OTA had identified in its earlier report, in light of recent developments in 
the private sector and in government. During the course of this work, 
OTA found that the need for timely attention to the security of unclassi¬ 
fied information has intensified in the months since the 1994 report was 
issued. 

OTA appreciates the participation of many individuals without whose 
help this background paper would not have been possible. OTA received 
valuable assistance from workshop participants and many other re¬ 
viewers and contributors from government, academia, and industry. The 
background paper itself, however, is the sole responsibility of OTA. 
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Director 
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Introduction 

and 

Summary 


C ontroversies, problems, and proposed solutions related to 
information security and privacy arc becoming increas¬ 
ingly prominent among government, business, academia, 
and the general public. At the same time, use of informa¬ 
tion networks for business has continued to expand, and ventures 
to bring electronic commerce and “electronic cash” into homes 
and offices are materializing rapidly. 1 Government agencies have 
continued to expand both the scale and scope of their network 
connectivities; information technologies and networks are fea¬ 
tured prominently in plans to make government more efficient, 
effective, and responsive. 2 

Until recently, topics such as intrusion countermeasures for 
computer networks or the merits of particular encryption tech¬ 
niques were mostly of interest to specialists. However, in the past 


1 See, e.g., Randy Barrett. "Hauling in the Network—Behind the World’s Digital Cash 
Curve,” Washington Technology, Oct. 27, 1994, p. 18; Neil Munro, “Branch Banks Go 
Way of the Drive-In,” Washington Technology, Feb. 23, 1995, pp. 1,48; Amy Cortese et 
al., “Cashing In on Cyberspace: A Rush of Software Development To Create an Electronic 
Marketplace,” Business Week, Feb. 27, 1995, pp. 78-86; Bob Metcalfe, “Internet Digital 
Cash—Don’t Leave Your Home Page Without It,” InfoWorld, Mar. 13,1995, p. 55; “Net¬ 
scape Signs Up 19 Users for Its System of Internet Security,” The Wall Street Journal, Mar. 
20,1995, p. B3; Saul Hansell, “VISA Will Put a Microchip in New Cards—Product Is De¬ 
signed for Small Purchases,” The New York Times, Mar. 21,1995, p. D3; Jorgen Wouters, 
“Brother, Can You Spare a Virtual Dime?” Washington Technology, Mar. 23,1995, pp. 1, 
44. 

2 See, e.g., Neil Munro, “Feds May Get New Infotech Executive,” Washington 
Technology, Feb. 23, 1995, pp. 1, 49; Charles A. Bowsher, Comptroller General of the 
United States, “Government Reform: Using Reengineering and Technology To Improve 
Government Performance,” GAO/T-OCG-95-2, testimony before the Committee on 
Governmental Affairs, U.S. Senate, Feb. 2, 1995; and Elena Varon, “Reinventing Is Old 
Hat for New Chairman,” Federal Computer Week, Feb. 20, 1995, pp. 22, 27. 
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few years, stories about controversial federal en¬ 
cryption standards, “password sniffing” and un¬ 
authorized intrusions on the Internet, the pursuit 
and capture of a notorious computer “cracker,” 
and export controls on computer programs that 
perform encryption have become front-page 
news. 3 

The increased visibility and importance ac¬ 
corded information security and privacy protec¬ 
tion (see box 1 -1) reflect a number of institutional, 
social, and technological changes that have made 
information technologies critical parts of daily 
life. 4 We are in transition to a society that is be¬ 
coming critically dependent on electronic in¬ 
formation and network connectivity. This is 
exemplified by the explosive growth of the Inter¬ 
net, which now has host computers in over 85 
countries, as well as the rapidly expanding variety 
of online sources of information, services, and en¬ 
tertainment. The growing dependence of both the 
public and private sectors on electronic informa¬ 
tion and networking makes the ability to safe¬ 
guard information and provide adequate privacy 
protections for individuals absolutely essential. 

In September 1994, the Office of Technology 
Assessment (OTA) released the report Informa¬ 
tion Security and Privacy in Network Environ¬ 
ments (see box 1-2). 5 That report was prepared in 
response to a request by the Senate Committee on 
Governmental Affairs and the House Subcommit¬ 
tee on Telecommunications and Finance. The 


need for congressional attention to safeguarding 
unclassified information has been reinforced in 
the months since the release of the OTA report. 

INTRODUCTION 

This background paper is part of OTA’s follow-on 
assistance to the Senate Committee on Govern¬ 
mental Affairs after the September 1994 OTA re¬ 
port on information security and privacy. The 
Committee had requested additional information¬ 
al and analytical assistance from OTA in order to 
prepare for heal ings and legislation in the 104th 
Congress (see the letter of request in appendix A). 

This background paper is a companion and sup¬ 
plement to the 1994 report and is intended to be 
used in conjunction with it. For the reader’s con¬ 
venience, however, pertinent technical and insti¬ 
tutional background material, drawn from that 
report and updated where possible, is included in 
this background in appendices B (“Federal In¬ 
formation Security and the Computer Security 
Act”), C (“U.S. Export Controls on Cryptogra¬ 
phy”), and D (“Summary of Issues and Options 
from the 1994 OTA Report”). 

One puipose of this background paper is to is to 
update some key issues that OTA had identified in 
the report, in light of recent developments. Anoth¬ 
er puipose is to develop further some of OTA’s 
findings and options, particularly as these relate to 
the effects of government policies on the private 


3 See John Markoff, “Flaw Discovered in Federal Plan for Wiretapping,” The New York Tunes, June 2, 1994, pp. 1, D17; Peter H. Lewis, 
“Hackers on Internet Posing Security Risks, Experts Say,” The New York Times, July 21, 1994, pp. 1, BIO; John Markoff, “A Most-Wanted 
Cyberthief Is Caught in His Own Web,” The New York Times, Feb. 16, 1995, pp. 1, D17; and John Schwartz, “Privacy Program: An On-Line 
Weapon?” The Washington Post, Apr. 3, 1995, pp. Al, A13. See also Jared Sandberg, “Newest Security Glitch on the Internet Could Affect 
Many ‘Host’ Computers,” The Wall Street Journal, Feb. 23, 1995, p. B8; Jared Sandberg, “Immorality Play: Acclaiming Hackers as Heroes,” 
The Wall Street Journal, Feb. 27, 1995, p. Bl, B8; and Amy Cortese et al., “Warding Off the Cyberspace Invaders,” Business Week, Mar. 13, 
1995, pp. 92-93. 

4 See U.S. Congress, Office of Technology Assessment, Making Government Work: Electronic Delivery of Government Services, OTA- 
TCT-578 (Washington, DC: U.S. Government Printing Office, September 1993); Electronic Enterprises: Looking to the Future, OTA-TCT-600 
578 (Washington, DC: U.S. Government Printing Office, May 1994); and Wireless Technologies and the National Information Infrastructure 
(forthcoming, 1995). See also U.S. General Accounting Office, Information Superhighway: An Overview of Technology Challenges, GAO/ 
AIMD-95-23 (Washington, DC: U.S. General Accounting Office, January 1995). 

5 U.S. Congress, Office of Technology Assessment, Information Security and Privacy in Network Environments, OTA-TCT-606 (Washing¬ 
ton, DC: U.S. Government Printing Office, September 1994). Available from OTA Online via anonymous file transfer protocol (ftp://otabbs. 
ota.gov/pub/information.security/) or World Wide Web (http://www.ota.gov). 
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BOX 1-1: Some Notes on Terminology 


Information Security 

There are three main aspects of information security: 1) confidentiality, 2) integrity, and 3) availability 
These protect against the unauthorized disclosure, modification, or destruction of information. The focus of 
this background paper, and the OTA report Information Security and Privacy in Network Environments 
(September 1994) that it supplements, is technical and institutional measures to ensure the confidentiality 
and integrity of unclassified electronic information in networks, not the security of the networks themselves. 
Network reliability and survivability (related to ‘(availability”) were not addressed; these topics are expected 
to be the focus of subsequent OTA work. 

Confidentiality and Privacy 

OTA uses the term confidentiality to refer to disclosure of information only to authorized individuals, 
entities, and so forth. Privacy refers to the social balance between an individual's right to keep information 
confidential and the societal benefit derived from sharing information, and how this balance is codified to 
give individuals the means to control personal information. The terms are not mutually exclusive: safe¬ 
guards that help ensure confidentiality of information can be used to protect personal privacy. 

information Safeguards and Security 

OTA often uses the term safeguard, as in ‘(information safeguards" or ‘(to safeguard information.” This is 
to avoid misunderstandings regarding use of the term “security,” which some readers may interpret in 
terms of classified information, or as excluding measures to protect personal privacy. In discussion of in¬ 
formation safeguards, the focus here is on technical and institutional measures to ensure the confidentiality 
and integrity of the information, and also the authenticity of its origin. 

Cryptography can be used to fulfill these functions for electronic information. Modern encryption tech¬ 
niques, for example, can be used to safeguard the confidentiality of the contents of a message (or a stored 
file). Integrity is used to refer to the property that the information has not been subject to unauthorized or 
unexpected changes. Authenticity refers to the property that the message or information comes from the 
stated source or origin. Message authentication techniques and digital signatures based on cryptography 
can be used to ensure the integrity of the message (that it has been received exactly as it was sent) and 
the authenticity of its origin (that it comes from the stated source). 

SOURCE: Office of Technology Assessment, 1995. For more detailed discussion of cryptographic safeguards, see OTA, Information 
Security and Privacy in Network Environments (OTA-TCT-606, September 1994), esp. ch. 2 and 4 and appendix C. 


sector and to federal-agency operations to safe¬ 
guard unclassified information. As in the 1994 re¬ 
port, the focus is on safeguarding unclassified 
information. OTA’s follow-on activities were con¬ 
ducted at the unclassified level and project staff 
did not receive or use any classified information 
during the course of this work. 

Chapter 2 of this background paper gives an 
overview of the 1994 report. It highlights the im¬ 
portance of information security and privacy 
issues, explains why cryptography and cryptogra¬ 
phy policies are so important, and reviews policy 


findings and options from the 1994 report. Chap¬ 
ter 3 identifies major themes that emerged from a 
December 1994 OTA workshop, particularly re¬ 
garding export controls and the international busi¬ 
ness environment, federal cryptography policy, 
and information-security “best practices.” Chap¬ 
ter 4 provides an update on recent and ongoing 
cryptography, privacy, and security-policy devel¬ 
opments and their relevance for possible congres¬ 
sional actions. 
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BOX 1-2: The 1994 OTA Re 


In September 1994, the Office of Technology Assessment released its report Information Security and 
Privacy in Network Environments.ln that report, OTA found that the fast-changing and competitive market¬ 
place that produced the Internet and strong networking and software industries in the United States has not 
consistently produced products equipped with affordable, user-friendly safeguards. Many individual prod¬ 
ucts and techniques are available to adequately safeguard specific information networks, if the user knows 
what to purchase, and can afford and correctly use the product, Nevertheless, better and more affordable 
products are needed. In particular, OTA found a need for products that integrate security features with 
other functions for use in electronic commerce, electronic mail, or other applications. 

OTA found that more study is needed to fully understand vendors’ responsibilities with respect to soft¬ 
ware and hardware product quality and liability. OTA also found that more study is also needed on the 
effects of export controls on the domestic and global markets for information safeguards, and on the ability 
of safeguard developers and vendors to produce more affordable, integrated products. OTA concluded 
that broader efforts to safeguard networked information will be frustrated unless cryptography-policy is¬ 
sues are resolved. 

OTA found that the single most important step toward implementing proper safeguards for networked 
information in a federal agency or other organization is for top management to define the organization’s 
overall objectives, define an organizational security policy to reflect those objectives, and implement that 
policy. Only top management can consolidate the consensus and apply the resources necessary to effec¬ 
tively protect networked information. For the federal government, this requires guidance from the Office of 
Management and Budget (e.g., in OMB Circular A-130), commitment from top agency management, and 
oversight by Congress. 

During the course of the assessment (1993-94), there was widespread controversy concerning the Clin¬ 
ton Administration’s escrowed-encryption initiative. The significance of this initiative, in concert with other 
federal cryptography policies, resulted in an increased focus in the report on the processes that the gov¬ 
ernment uses to regulate cryptography and to develop federal information processing standards (the FIPS) 
based on cryptography. 

The 1994 OTA report concluded that Congress has a vital role in formulating national cryptography policy 
and in determining how we safeguard information and protect personal privacy in an increasingly networked 
society (see the expanded discussion in appendix D of this background paper). Policy issues and options 
were identified in three areas: 1 ) cryptography policy, including federal information processing standards and 
export controls; 2) guidance on safeguarding unclassified information in federal agencies; and 3) legal issues 
and information security, including electronic commerce, privacy, and intellectual property. 

SOURCE: Office of Technology Assessment, 1995; based on Information Security and Privacy in Network Environments (OTA- 
TCT-606, September 1994). 


INFORMATION SECURITY AND 
PRIVACY IN A NETWORKED SOCIETY 

Information technologies are transforming the 
ways in which we create, gather, process, and 
share information. Rapid growth in computer net¬ 
working is driving many of these changes; elec¬ 
tronic transactions and electronic records are 
becoming central to everything from business to 


health care. Within the federal government, effec¬ 
tive use of information technologies and networks 
is central to government restructuring and reform. 

The transformation being brought about by net¬ 
working brings with it new concerns for the secu¬ 
rity of networked information and for our ability 
to maintain effective privacy protections in net¬ 
worked environments. Unless these concerns can 


< 
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be resolved, they threaten to limit networking’s 
full potential in terms of both participation and 
usefulness. Therefore, information safeguards 
(countermeasures) are achieving new promi¬ 
nence. Appropriate safeguards for the networked 
environment must account for—and anticipate— 
technical, institutional, and social changes that in¬ 
creasingly shift responsibility for security to the 
end users. 

Computing power used to be isolated in large 
mainframe computers located in special facilities; 
computer system administration was centralized 
and carried out by specialists. In today’s net¬ 
worked environment, computing power is de¬ 
centralized to diverse users who operate desktop 
computers and who may have access to comput¬ 
ing power and data at remote locations. Distrib¬ 
uted computing and open systems can make every 
user essentially an “insider.” In such a decentral¬ 
ized environment, responsibility for safeguarding 
information is distributed to the users, rather than 
remaining the purview of system specialists. The 
increase in the number and variety of network ser¬ 
vice providers also requires that users take respon¬ 
sibility for safeguarding information, rather than 
relying on intermediaries to provide adequate 
protection. 6 

The new focus is on safeguarding the informa¬ 
tion itself as it is processed, stored, and trans¬ 
mitted. This contrasts with older, more static or 
insulated concepts of “document” security or 
“computer” security. In the networked environ¬ 
ment, we need appropriate rules for handling 
proprietary, copyrighted, and personal informa¬ 
tion—and tools with which to implement them. 7 


Increased interactivity means that we must also 
deal with transactional privacy, as well as prevent 
fraud in electronic commerce and ensure that safe¬ 
guards are integrated as organizations streamline 
their operations and modernize their information 
systems. 

I Importance of Cryptography 

Cryptography (see box 2-1 on page 46) is not ar¬ 
cane anymore. It is a technology whose time has 
come—in the marketplace and in society. In its 
modern setting, cryptography has become a fun¬ 
damental technology with broad applications. 

Modern, computer-based cryptography began 
in the World War II era. 8 Much of this develop¬ 
ment has been shrouded in secrecy; in the United 
States, governmental cryptographic research has 
historically been the purview of the “national 
security” (i.e., defense and intelligence) commu¬ 
nities. Despite two decades of growth in nongov¬ 
ernmental research and development, in the 
United States, the federal government still has the 
most expertise in cryptography. Nevertheless, 
cryptography is not just a “government technolo¬ 
gy” anymore, either. 

Because it is a technology of broad application, 
the effects of federal policies about cryptography 
are not limited to technological developments in 
the field, or even to the health and vitality of com¬ 
panies that produce or use products incorporating 
cryptography. Instead, these policies will increas¬ 
ingly affect the everyday lives of most Americans. 

Encryption (see box 2-2 on page 48) transforms 
a message or data files into a form that is unintelli- 


6 The trend is toward decentralized, distributed computing, rather than centralized, mainframe computing. Distributed computing is rela- 
tively informal and “bottom up,” compared with mainframe computing, and systems administration may be less rigorous. See OTA, op. cit., 
footnote 5, pp. 3-5, 25-32. 

7 See ibid., chapter 3. “Security” technologies like encryption can be used to help protect privacy and the confidentiality of proprietary 
information; some, like digital signatures, could be used to facilitate copyright-management systems. 

8 See, e.g., David Kahn, The Codebreakers (New York, NY: MacMillan, 1967). 


6 | Issue Update on Information Security and Privacy in Network Environments 


gible without special knowledge of some secret 
information (called the “decryption key”). 9 En¬ 
cryption can be used as a tool to protect the 
confidentiality of information in messages or 
files—hence, to help protect personal privacy. 
Other applications of cryptography can be used to 
protect the integrity of information (that it has not 
been subject to unauthorized or unexpected 
changes) and to authenticate its origin (that it 
comes from the stated source or origin and is not a 
forgery). 

Thus, cryptography is a technology that will 
help speed the way to electronic commerce. With 
the advent of what are called public-key tech¬ 
niques, cryptography came into use for digital sig¬ 
natures (see figure 2-3 on page 52) that are of 
widespread interest as a means for electronically 
authenticating and signing commercial transac¬ 
tions like purchase orders, tax returns, and funds 
transfers, as well as for ensuring that unauthorized 
changes or errors are detected (see discussion of 
message authentication and digital signatures in 
box 2-2). 10 These functions are critical for elec¬ 
tronic commerce. Cryptographic techniques like 
digital signatures can also be used to help manage 
copyrighted material in electronic form. 11 

The nongovernmental markets for cryptogra¬ 
phy-based safeguards have grown over the past 
two decades, but are still developing. Good com¬ 
mercial encryption technology is available in the 


United States and abroad. Research in cryptogra¬ 
phy is international. Markets for cryptography 
also would be international, except for govern¬ 
mental restrictions (i.e., export controls), that ef¬ 
fectively create “domestic” and “export” market 
segments for strong encryption products (see sec¬ 
tion on export controls below and also appendix 
C. 12 User-friendly cryptographic safeguards that 
are integrated into products (as opposed to those 
that the user has to acquire separately and add on) 
are still hard to come by—in part, because of ex¬ 
port controls and other federal policies that seek to 
control cryptography. 13 

Cryptography and related federal policies (e.g., 
regarding export controls and standards develop¬ 
ment) were a major focus of the 1994 OTA re¬ 
port. 14 That focus was due in part from the 
widespread attention being given the so-called 
Clipper chip and the escrowed-encryption initia¬ 
tive announced by the Clinton Administration in 
1993. Escrowed encryption, or key-escrow en¬ 
cryption, refers to an encryption method where the 
functional equivalent of a “spare key” must be de¬ 
posited with a third party. The rationale for key- 
escrow encryption is to ensure government access 
to decryption keys when encrypted messages are 
encountered in the course of lawful electronic sur¬ 
veillance (see box 2-3 on page 54). The Escrowed 
Encryption Standard (EES), promulgated as a fed- 


9 Figures 2-1 and 2-2 on pages 50 and 51 illustrate two common forms of encryption: secret-key (or symmetric) encryption and public-key 
(or asymmetric) encryption. Note that key management—the generation of encryption and decryption keys, as well as their storage, distribu¬ 
tion, cataloging, and eventual destruction—is crucial for the overall security of any encryption system. 

10 OTA, op. cit., footnote 5, pp. 69-77. See Peter H. Lewis, “Accord Is Reached on a Common Security System for the Internet,” The New 
York Times, Apr. 11, 1995, p. D5. 

11 OTA, ibid., pp. 96-110. For example, digital signatures can be used to create compact “copyright tokens” for use in registries; encryption 
could be used to create personalized “copyright envelopes” for direct electronic delivery of material to customers. See also Working Group on 
Intellectual Property Rights, IITF, “Intellectual Property and the National Information Infrastructure (Green Paper),” July 1994, pp. 139-140. 

12 OTA, ibid., pp. 11-13, 150-160. 

13 Ibid., pp. 115-123, 128-132, 154-160. 

14 Ibid., pp. 8-18 and chapter 4. 
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eral information processing standard (FIPS) in 
1994, is intended for use in encrypting unclassi¬ 
fied voice, fax, or data communicated in a tele¬ 
phone system. 15 At present, all the Clipper chip 
(i.e., EES) “spare keys” are held within the execu¬ 
tive branch. 

I Government Efforts 
To Control Cryptography 

In its activities as a developer, user, and regulator 
of safeguard technologies, the federal government 
faces a fundamental tension between two policy 
objectives, each of which is important: 1) fos¬ 
tering the development and widespread use of 
cost-effective information safeguards; and 2) con¬ 
trolling the proliferation of safeguard technolo¬ 
gies that can impair U.S. signals-intelligence and 
law enforcement capabilities. Cryptography is at 
the heart of this tension. Export controls and the 
federal standards process (i.e., the development 
and promulgation of federal information process¬ 
ing standards, or FIPS) are two mechanisms the 
government can use to control cryptography. 16 

Policy debate over cryptography used to be as 
arcane as the technology itself. Even 5 or 10 years 
ago, few people saw a link between government 
decisions about cryptography and their daily 
lives. However, as the information and commu¬ 
nications technologies used in daily life have 
changed, concern over the implications of policies 
traditionally dominated by national security ob¬ 
jectives has grown dramatically. 


Previously, control of the availability and use 
of cryptography was presented as a national secu¬ 
rity issue focused outward, with the intention of 
maintaining a U.S. technological lead over other 
countries and preventing encryption devices from 
falling into the “wrong hands” overseas. More 
widespread foreign use—including use of strong 
encryption by terrorists and developing coun¬ 
tries—makes U.S. signals intelligence more diffi¬ 
cult. 

Now. with an increasing policy focus on do¬ 
mestic crime and terrorism, the availability and 
use of cryptography has also come into promi¬ 
nence as a domestic-security, law enforcement is¬ 
sue. 17 Within the United States, strong encryption 
is increasingly portrayed as a threat to domestic 
security (public safety) and a barrier to law en¬ 
forcement if it is readily available for use by ter¬ 
rorists or criminals: 

. . . Powerful encryption threatens to make 
worthless the access assured by the new digital law 
[i.e., the Communications Assistance for Law En¬ 
forcement Act ]. 18 

Thus, export controls, intended to restrict the in¬ 
ternational availability of U.S. cryptography 
technology and products, are now being joined 
with domestic cryptography initiatives, like key- 
escrow encryption, that are intended to preserve 
U.S. law enforcement and signals-intelligence ca¬ 
pabilities. 

Standards-development and export-control is¬ 
sues underlie a long history of concern over lead- 


15 The EES is implemented in hardware containing the Clipper chip. The EES (FIPS-185) specifies use of a classified, symmetric encryption 
algorithm, called Skipjack , which was developed by the National Security Agency. The Capstone chip implements the Skipjack algorithm for 
use in computer network applications. The Defense Department’s FORTEZZA card (a PCMCIA card formerly called TESSERA ) contains the 
Capstone chip. 

16 For more detail, see OTA, op. cit., footnote 5, chapters 1 and 4 and appendix C. Other means of control have historically included national 
security classification and patent-secrecy orders (see ibid., p. 128 and footnote 33). 

17 There is also growing organizational recognition of potentials for misuse of encryption, such as by disgruntled employees as a means to 
sabotage an employer’s databases. Thus, some “commercial key-escrow” or “data recovery” facilities are being developed in the private sector 
(see discussion below and in ch. 4). 

18 Louis J. Freeh, Director, Federal Bureau of Investigation, testimony before the U.S. Senate, Committee on the Judiciary, Feb. 14, 1995, 
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ership and responsibility (i.e., “who should be in 
charge?” and “who is in charge?”) for the secu¬ 
rity of unclassified information government¬ 
wide. 19 Most recently, these concerns have been 
revitalized by proposals presented by the Clinton 
Administration’s Security Policy Board staff 20 to 
centralize information-security authorities under 
joint control of the Office of Management and 
Budget (OMB) and Defense Department (see dis¬ 
cussion below and in chapter 4). 

Other manifestations of these concerns can be 
found in the history of the Computer Security Act 
of 1987 (see below and appendix B) and in more 
recent developments, such as public reactions to 
the Clinton Administration’s key-escrow encryp¬ 
tion initiative and the controversial issuances of 
the Escrowed Encryption Standard 21 and Digital 
Signature Standard (DSS) 22 as federal informa¬ 
tion processing standards. Another important 
manifestation of these concerns is the controversy 
over the present U.S. export control regime, 
which includes commercial products with capa¬ 
bilities for strong encryption, including mass- 
market software, on the Munitions List, under 
State Department controls (see below and appen¬ 
dix C). 

I Federal Information 
Processing Standards 

The 1994 OTA report concluded that two recent 
federal information processing standards based 
on cryptography are part of a long-term control 
strategy intended to retard the general, uncon¬ 
trolled availability of strong encryption within the 


United States, for reasons of national security and 
law enforcement. 23 OTA viewed the Escrowed 
Encryption Standard and the Digital Signature 
Standard as complements in this overall control 
strategy, intended to discourage future develop¬ 
ment and use of encryption without built-in law 
enforcement access, in favor of key-escrowed en¬ 
cryption and related encryption technologies. If 
the EES and/or other key-escrow encryption stan¬ 
dards (e.g., for use in computer networks) become 
widely used (or, at least, enjoy a large, guaranteed 
government market), this could ultimately reduce 
the variety of alternative cryptography products 
through market dominance that makes alterna¬ 
tives more scarce or more costly. 

The Escrowed Encryption Standard is a federal 
information processing standard that uses a classi¬ 
fied algorithm, called “Skipjack,” developed by 
the National Security Agency (NSA). It was pro¬ 
mulgated as a voluntary federal information proc¬ 
essing standard. The Commerce Department’s 
announcement of the EES noted that the standard 
does not mandate the use of escrowed-encryption 
devices by government agencies or the private 
sector; rather, the standard provides a mechanism 
for agencies to use key-escrow encryption without 
having to waive the requirements of another, ex¬ 
tant federal encryption standard for unclassified 
information, the Data Encryption Standard 
(DES). 24 

The secret encryption/decryption key for Skip¬ 
jack is 80 bits long. A key-escrowing scheme is 
built in to ensure “lawfully authorized” electronic 
surveillance. 25 The algorithm is classified and is 


19 OTA, op. cit., footnote 5, pp. 8-20 and chapter 4. 

20 U.S. Security Policy Board Staff, “Creating a New Order in U.S. Security Policy,” Nov. 21, 1994, pp. II-III, 14-18. 

21 See box 2-3 in chapter 2 of this background paper and OTA, op. cit., footnote 5, chapter 4. 

22 See box 2-2 in chapter 2 of this background paper and OTA, ibid., appendix C. 

23 See OTA, op. cit., footnote 5, chapter 4. 

24 See Federal Register , vol. 59, Feb. 9, 1994, pp. 5997-6005 (“Approval of Federal Information Processing Standards Publication 185, 
Escrowed Encryption Standard (EES)”), especially p. 5998. Note however, that the DES is approved for encryption of unclassified data com¬ 
munications and files, while the EES is only a standard for telephone communications at this time. 

25 Federal Register , op. cit., footnote 22, p. 6003. 
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intended to be implemented only in tamper-resis¬ 
tant, hardware modules. 26 This approach makes 
the confidentiality function of the Skipjack en¬ 
cryption algorithm available in a controlled fash¬ 
ion, without disclosing the algorithm’s design 
principles or thereby increasing users’ abilities to 
employ cryptographic principles. One of the rea¬ 
sons stated for specifying a classified, rather than 
published, encryption algorithm in the EES is to 
prevent independent implementation of Skipjack 
without the law enforcement access features. 

The EES is intended for use in encrypting un¬ 
classified voice, fax, and computer information 
communicated over a telephone system. The 
Skipjack algorithm can also be implemented for 
data encryption in computer networks; the De¬ 
fense Department is using it in the Defense Mes¬ 
sage System. At this writing, however, there is no 
FIPS specifying use of Skipjack as a standard al¬ 
gorithm for data communications or file encryp¬ 
tion. Given that the Skipjack algorithm was 
selected as a standard for telephony, it is possible 
that an implementation of Skipjack (or some other 
form of key-escrow encryption) will be selected as 
a FIPS to replace the DES for computer commu¬ 
nications and/or file encryption. An alternative 
successor to the DES that is favored by nongov¬ 
ernmental users and experts is a variant of DES 
called triple-encryption DES. There is, however, 
no FIPS for triple-encryption DES. 

Unlike the Skipjack algorithm, the algorithm in 
the federal Digital Signature Standard has been 
published. 27 The public-key algorithm specified 
in the DSS uses a private key in signature genera¬ 


tion, and a corresponding public key for signature 
verification (see box 2-2). However, the DSS 
technique was chosen so that public-key encryp¬ 
tion functions would not be available to users. 28 
This is significant because public-key encryption 
is extremely useful for key management and 
could, therefore, contribute to the spread and use 
of nonescrowed encryption. 29 While other means 
of exchanging electronic keys are possible, 30 none 
is so mature as public-key technology. In contrast 
to the technique chosen for the DSS, the technique 
used in the most popular commercial digital sig¬ 
nature system (based on the Rivest-Shamir-Adle- 
man, or RSA, algorithm) can also encrypt. 
Therefore, the RSA techniques can be used for se¬ 
cure key exchange (i.e., exchange of “secret” 
keys, such as those used with the DES), as well as 
for signatures. At present, there is no FIPS for key 
exchange. 

I Federal Standards and the 
Computer Security Act of 1987 

The Computer Security Act of 1987 (Public Law 
100-235) is fundamental to development of feder¬ 
al standards for safeguarding unclassified in¬ 
formation, to balancing national security and 
other objectives in implementing security and pri¬ 
vacy policies within the federal government, and 
to other issues concerning government control of 
cryptography. Implementation of the Computer 
Security Act has been controversial, especially re¬ 
garding the respective roles of the National Insti¬ 
tute of Standards and Technology (NIST) and 


26 Federal Register, ibid., pp. 5997-6005. 

27 See appendix C of OTA, op. cit., footnote 5. for a history of the DSS. 

28 According to F. Lynn McNulty, NIST Associate Director for Computer Security, the rationale for adopting the technique used in DSS was 
that, “We wanted a technology that did signatures—and nothing else—very well." (Response to a question from Chairman Rick Boucher in 
testimony before the Subcommittee on Science of the House Committee on Science, Space, and Technology, Mar. 22, 1994.) 

27 Public-key encryption can be used for confidentiality and, thereby, for secure key exchange. Thus, public-key encryption can facilitate 
the use of symmetric encryption methods like the DES or triple DES. See figure 2-3. 

20 See, e.g., Tom Leighton, Department of Mathematics, Massachusetts Institute of Technology and Silvio Micali, MIT Laboratory for 
Computer Science, “Secret-Key Agreement Without Public-Key Cryptography (Extended Abstract),” obtained from S. Micali, 1993. 
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NSA in standards development and the chronic 
shortage of resources for NIST’s computer securi¬ 
ty program to fulfill its responsibilities under the 
act (see detailed discussion in chapter 4 of the 
1994 OTA report). 31 

The Computer Security Act of 1987 was a leg¬ 
islative response to overlapping responsibilities 
for computer security among several federal agen¬ 
cies, heightened awareness of computer security 
issues, and concern over how best to control in¬ 
formation in computerized or networked form. 
The act established a federal government com¬ 
puter-security program that would protect all un¬ 
classified, sensitive information in federal 
government computer systems and would devel¬ 
op standards and guidelines to facilitate such 
protection. The act also established a Computer 
System Security and Privacy Advisory Board 
(CSSPAB). The board, appointed by the Secretary 
of Commerce, is charged with identifying emerg¬ 
ing safeguard issues relative to computer systems 
security and privacy, advising the former National 
Bureau of Standards (now NIST) and the Secre¬ 
tary of Commerce on security and privacy issues 
pertaining to federal computer systems. The 
CSSPAB reports its findings to the Secretary of 
Commerce, the Director of OMB, the Director of 
NSA, and to the “appropriate committees of the 
Congress.” Additionally, the act required federal 
agencies to identify computer systems containing 
sensitive information, to develop security plans 
for identified systems, and to provide periodic 
training in computer security for all federal em¬ 
ployees and contractors who manage, use, or oper¬ 
ate federal computer systems. Appendix B, drawn 
from the 1994 OTA report, provides more back¬ 


ground on the puipose and implementation of the 
Computer Security Act and on the FIPS. 

The Computer Security Act assigned responsi¬ 
bility for developing government-wide, comput¬ 
er-system security standards (e.g., the FIPS) and 
security guidelines and security-training pro¬ 
grams to the National Bureau of Standards. Ac¬ 
cording to its responsibilities under the act, NIST 
recommends federal information processing stan¬ 
dards and guidelines to the Secretary of Com¬ 
merce for approval (and promulgation, if 
approved). These FIPS do not apply to classified 
or “Warner Amendment” systems. 32 NIST can 
draw on the technical expertise of the National Se¬ 
curity Agency in carrying out its responsibilities, 
but NSA’s role according to the Computer Securi¬ 
ty Act, is an advisory, rather than leadership, one. 

I Federal Standards and the Marketplace 

As the 1994 OTA report noted, not all government 
attempts at influencing the marketplace through 
the FIPS and procurement polices are successful. 
Flowever, the FIPS usually do influence the 
technologies used by federal agencies and provide 
a basis for interoperability, thus creating a large 
and stable “target market” for safeguard vendors. 
If the attributes of the standard technology are also 
applicable to the private sector and the standard 
has wide appeal, an even lai gcr but still relatively 
stable market should result. The technological sta¬ 
bility means that firms compete less in terms of 
the attributes of the fundamental technology and 
more in terms of cost, ease of use, and so forth. 
Therefore, firms need to invest less in research and 
development (especially risky for a complex 


31 OTA, op. cit., footnote 5 and chapter 4 and appendix B. NIST’s FY 1995 computer-security budget was on the order of $6.5 million, with 
$4.5 million of this coming from appropriated funds for “core” activities and the remainder from “reimbursable” funds from other agencies, 
mainly the Defense Department. 

32 The Warner Amendment (Public Law 97-86) excluded certain types of military and intelligence “automatic data processing equipment” 
procurements from the requirements of section 111 of the Federal Property and Administrative Services Act of 1949 (40 U.S.C. 795). Public 
Law 100-235 pertains to federal computer systems that come under section 111 of the Federal Property and Administrative Services Act of 
1949. 
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technology like cryptography) and in convincing 
potential customers of product quality. This can 
result in higher profits for producers, even in the 
long run, and in increased availability and use of 
safeguards based on the standard. 

In the 1970s, promulgation of the Data Encryp¬ 
tion Standard as a stable and certified technolo¬ 
gy—at a time when the commercial market for 
cryptography-based safeguards for unclassified 
information was just emerging—stimulated sup¬ 
ply and demand. Although the choice of the algo¬ 
rithm was originally controversial due to concerns 
over NS A’s involvement, the DES gained wide ac¬ 
ceptance and has been the basis for several indus¬ 
try and international standards, in large paid 
because it was a published standard that could be 
freely evaluated and implemented. The process by 
which the DES was developed and evaluated also 
stimulated private sector interest in cryptographic 
research, ultimately increasing the variety of com¬ 
mercial safeguard technologies. Although domes¬ 
tic products implementing the DES are subject to 
U.S. export controls, DES-based technology is 
available overseas. 

The 1994 OTA report regarded the introduction 
of an incompatible new federal standard—for ex¬ 
ample, the Escrowed Encryption Standard—as 
destabilizing. At present, the EES and other im¬ 
plementations of Skipjack (e.g., for data commu¬ 
nications) have gained little favor in the private 
sector. Features such as the government key-es¬ 
crow agencies, classified algorithm, and hard- 
ware-only implementation all contribute to the 
lack of appeal. But, if key-escrow encryption 
technologies ultimately do manage to gain wide 
appeal in the marketplace, they might be able to 
“crowd out” safeguards that are based upon other 
cryptographic techniques and/or do not support 
key escrowing. 33 

The 1994 OTA report noted that this type of 
market distortion, intended to stem the supply of 


alternative products, may be a long-term objective 
of the key-escrow encryption initiative. In the 
long term, a loss of technological variety is signif¬ 
icant to private sector cryptography, because more 
diverse research and development efforts tend to 
increase the overall pace of technological ad¬ 
vance. In the near term, technological uncertainty 
may delay widespread investments in any new 
safeguard, as users wait to see which technology 
prevails. The costs of additional uncertainties and 
delays due to control interventions are ultimately 
borne by the private sector and the public. 

Other government policies can also raise costs, 
delay adoption, or reduce variety. For example, 
export controls have the effect of segmenting do¬ 
mestic and export encryption markets. This 
creates additional disincentives to invest in the de¬ 
velopment—or use—of robust, but nonexport¬ 
able, products with integrated strong encryption 
(see discussion below). 

I Export Controls 

Another locus of concern is export controls on 
cryptography. 34 The United States has two regula¬ 
tory regimes for exports, depending on whether 
the item to be exported is military in nature, or is 
“dual-use,” having both civilian and military uses 
(see appendix C). These regimes are administered 
by the State Department and the Commerce De¬ 
partment, respectively. Both regimes provide ex¬ 
port controls on selected goods or technologies for 
reasons of national security or foreign policy. Li¬ 
censes are required to export products, services, or 
scientific and technical data originating in the 
United States, or to re-export these from another 
country. Licensing requirements vary according 
to the nature of the item to be exported, the end 
use, the end user, and, in some cases, the intended 
destination. For many items under Commerce ju¬ 
risdiction, no specific approval is required and a 


33 OTA, op. cit., footnote 5. pp. 128-132. A large, stable, lucrative federal market could divert vendors from producing alternative, riskier 
products; product availability could draw private sector customers. 

34 For more detail, see ibid, and chapters 1 and 4. 
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“general license” applies (e.g., when the item in 
question is not military or dual-use and/or is wide¬ 
ly available from foreign sources). In other cases, 
an export license must be applied for from either 
the State Department or the Commerce Depart¬ 
ment, depending on the nature of the item. In 
general, the State Department’s licensing require¬ 
ments are more stringent and broader in scope. 35 

Software and hardware for robust, user-con- 
trolled encryption are under State Department 
control, unless State grants jurisdiction to Com¬ 
merce. This has become increasingly controver¬ 
sial, especially for the information technology and 
software industries. 36 The impact of export con¬ 
trols on the overall cost and availability of safe¬ 
guards is especially troublesome to business and 
industry at a time when U.S. high-technology 
firms find themselves as targets for sophisticated 
foreign-intelligence attacks and thus have urgent 
need for sophisticated safeguards that can be used 
in operations worldwide, as well as for secure 
communications with overseas business partners, 


suppliers, and customers. 37 Software producers 
assert that, although other countries do have ex¬ 
port and/or import controls on cryptography, sev¬ 
eral countries have more relaxed export controls 
on cryptography than does the United States. 38 

On the other hand, U.S. export controls may 
have substantially slowed the proliferation of 
cryptography to foreign adversaries over the 
years. Unfortunately, there is little public explana¬ 
tion regarding the degree of success of these ex¬ 
port controls and the necessity for maintaining 
strict controls on strong encryption in the face of 
foreign supply 39 and networks like the Internet 
that seamlessly cross national boundaries. 40 

Appendix C of this background paper, drawn 
from the 1994 OTA report, provides more back¬ 
ground on export controls on cryptography. In 
September 1994, after the OTA report had gone to 
press, the State Department announced an amend¬ 
ment to the regulations implementing section 38 
of the Arms Export Control Act. The new rule irn- 


35 Ibid., pp. 150-154. 

36 To ease some of these burdens, the State Department announced new licensing procedures on Feb. 4,1994. These changes were expected 
to include to include license reform measures for expedited distribution (to reduce the need to obtain individual licenses for each end user), rapid 
review of export license applications, personal-use exemptions for U.S. citizens temporarily taking encryption products abroad for their own 
use, and special licensing arrangements allowing export of key-escrow encryption products (e.g., EES products) to most end users. At this writ¬ 
ing, expedited-distribution reforms were in place ( Federal Register , Sept. 2, 1994, pp. 45621-45623), but personal-use exemptions were still 
under contention (Karen Hopkinson, Office of Defense Trade Controls, personal communication, Mar. 8, 1995). 

37 See, e.g., U.S. Congress, House of Representatives, Subcommittee on Economic and Commercial Law, Committee on the Judiciary, The 
Threat of Foreign Economic Espionage to U.S. Corporations, hearings, 102d Congress, 2d sess., Apr. 29 and May 7,1992, Serial No. 65 (Wash¬ 
ington, DC: U.S. Government Printing Office, 1992). See also discussion of business needs and export controls in chapter 3 of this background 
paper. 

38 OTA, op. cit., footnote 5, pp. 154-160. Some other countries do have stringent export and/or import restrictions. 

39 For example, the Software Publishers Association has studied the worldwide availability of encryption products and, as of October 1994, 
found 170 software products (72 foreign, 98 U.S.-made) and 237 hardware products (85 foreign, 152 U.S.-made) implementing the DES algo¬ 
rithm for encryption. (Trusted Information Systems, Inc. and Software Publishers Association, Encryption Products Database Statistics, Octo¬ 
ber 1994.) Also see OTA, op. cit., footnote 5, pp. 156-160. 

40 For a discussion of export controls and network dissemination of encryption technology, see Simson Garfinkle, PGP: Pretty Good Priva¬ 
cy (Sebastopol, CA; O’Reilly and Assoc., 1995). PGP is an encryption program developed by Phil Zimmerman. Variants of the PGP software 
(some of which are said to infringe the RS A patent in the United States) have spread worldwide over the Internet. Zimmerman has been under 
grand jury investigation since 1993 for allegedly breaking the munitions export-control laws by permitting the software to be placed on an 
Internet-accessible bulletin board in the United States in 1991. (See Vic Sussman, “Lost in Kafka Territory,” U.S. News and World Report, Apr. 
3, 1995, pp. 30-31.) 
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plements one of the reforms applicable to encryp¬ 
tion products that were announced on February 4, 
1994, by the State Department. 41 Other an¬ 
nounced reforms, still to be implemented, include 
special licensing procedures allowing export of 
key-escrow encryption products to “most end us¬ 
ers.” 42 The ability to export strong, key-escrow 
encryption products would presumably increase 
escrowed-encryption products’ appeal to private- 
sector safeguard developers and users. 

In the 103d Congress, legislation intended to 
streamline export controls and ease restrictions on 
mass-market computer software, hardware, and 
technology, including certain encryption soft¬ 
ware, was introduced by Representative Maria 
Cantwell (H.R. 3627) and Senator Patty Murray 
(S. 1846). In considering the Omnibus Export Ad¬ 
ministration Act of 1994 (H.R. 3937), the House 
Committee on Foreign Affairs reported a version 
of the bill in which most computer software (in¬ 
cluding software with encryption capabilities) 
was under Commerce Department controls and in 
which export restrictions for mass-market soft¬ 
ware with encryption were eased. In its report, the 
House Permanent Select Committee on Intelli¬ 
gence struck out this portion of the bill and re¬ 
placed it with a new section calling for the 
President to report to Congress within 150 days of 
enactment, regarding the current and future in¬ 
ternational market for software with encryption 
and the economic impact of U.S. export controls 
on the U.S. computer software industry. 41 


At the end of the 103d Congress, omnibus ex¬ 
port administration legislation had not been en¬ 
acted. Both the House and Senate bills contained 
language calling for the Clinton Administration to 
conduct comprehensive studies on the interna¬ 
tional market and availability of encryption 
technologies and the economic effects of U.S. ex¬ 
port controls. In a July 20, 1994, letter to Repre¬ 
sentative Cantwell, Vice President Gore had 
assured her that the “best available resources of 
the federal government” would be used in con¬ 
ducting these studies and that the Clinton Admin¬ 
istration would “reassess our existing export 
controls based on the results of these studies.” 44 

At this writing, the Commerce Department and 
NSA are assessing the economic impact of U.S. 
export controls on cryptography on the U.S. com¬ 
puter software industry. 45 As part of the study, 
NSA is determining the foreign availability of en¬ 
cryption products. The study is scheduled to be 
delivered to the National Security Council by July 
1, 1995. According to the National Security 
Council (NSC), it is anticipated that there will be 
both classified and an unclassified sections of the 
study; there may be some public release of the un¬ 
classified material. 46 In addition, an ongoing Na¬ 
tional Research Council (NRC) study that would 
support a broad congressional review of cryptog¬ 
raphy (and that is expected to address export con¬ 
trols) is due to be completed in 1996. 47 At this 


41 Department of State, Bureau of Political-Military Affairs. 22 CFR parts 123 and 124 , Federal Register, vol. 59, No. 170, Sept. 2,1994, pp. 
45621-45623. See note 36 above and also ch. 4 of the 1994 OTA report. The reform established a new licensing procedure to permit U.S. encryp¬ 
tion manufacturers to make multiple shipments of some encryption items directly to end users in approved countries, without obtaining individ¬ 
ual licenses (see appendix C). 

42 Martha Harris, Deputy Assistant Secretary for Political-Military Affairs, U.S. Department of State, “Encryption—Export Control Re¬ 
form,” statement, Feb. 4, 1994. See OTA, op. cit., footnote 5, pp. 159-160. 

43 A study of this type (see below) is expected to be completed in mid-1995. 

44 Vice President A1 Gore, letter to Representative Maria Cantwell, July 20, 1994. See OTA, op. cit., footnote 5, pp. 11-13. 

45 Maurice Cook, Bureau of Export Administration, Department of Commerce, personal communication, Mar. 7, 1995. 

46 Bill Clements, National Security Council, personal communication, Mar. 21, 1995. 

47 For information about the NRC study, which was mandated by Public Law 103-160, contact Herb Lin, National Research Council, 2101 
Constitution Avenue, NW, Washington, DC 20418 (crypto@nas.edu). See discussion in OTA, op. cit., footnote 5, chapters 1 and 4. 
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writing, the NRC study committee is gathering 
public input on cryptography issues. 

In the 104th Congress, Representative Toby 
Roth has introduced the “Export Administration 
Act of 1995” (H.R. 361). This bill did not include 
any specific references to cryptography. At this 
writing, it is not clear whether or when the conten¬ 
tious issue of cryptography export controls will 
become paid of legislative deliberations. 

Alternatively, the Clinton Administration 
could ease export controls on cryptography with¬ 
out legislation. As was noted above, being able to 
export key-escrow encryption products would 
presumably make escrowed-encryption products 
more attractive to commercial developers and us¬ 
ers. Therefore, the Clinton Administration could 
ease export requirements for products with inte¬ 
grated key escrowing as an incentive for the com¬ 
mercial development and adoption of such 
products (see discussion of cryptography initia¬ 
tives below and in chapter 4). 

OTA WORKSHOP FINDINGS 

At the request of the Senate Committee on Gov¬ 
ernmental Affairs, OTA held a workshop titled 
“Information Security and Privacy in Network 
Environments: What Next?” on December 6, 
1994 as paid of its follow-on activities after the re¬ 
lease of the 1994 report. Workshop participants 
came from the business, legal, university, and 
public-interest communities. One workshop ob¬ 
jective was to gauge participants’ overall reac¬ 
tions to the OTA report Information Security and 
Privacy in Network Environmen ts. Another was to 
identify related topics that merited attention and 
that OTA had not already addressed (e.g., network 
reliability and survivability or “corporate” pri¬ 
vacy—see chapter 3). A third objective was for 
participants to identifyas specifically as possi- 
bleareas ripe for congressional action. 

The general areas of interest were: 

1. the marketplace for information safeguards 
and factors affecting supply and demand; 

2. information-security “best practices” in the 
private sector, including training and imple¬ 


mentation, and their applicability to govern¬ 
ment information security; 

3. the impacts of federal information-security and 
policies on business and the public; and 

4. desirable congressional actions and suggested 
time frames for any such actions. 

Chapter 3 of this background paper highlights 
major points and opinions expressed by the work¬ 
shop participants. It is important to note that the 
presentation in chapter 3 and the summary below 
are not intended to represent conclusions reached 
by the participants; moreover, the reader should 
not infer any general consensus, unless consensus 
is specifically noted. 

Several major themes emerged from the discus¬ 
sion regarding export controls and the business 
environment, federal cryptography policy, and 
characteristics of information-security “best prac¬ 
tices” that are germane to consideration of govern¬ 
ment information security. These have particular 
significance, especially in the context of current 
developments, for congressional consideration of 
several of the information-security issues and op¬ 
tions identified in the 1994 OTA report. These 
themes include: 

The mismatch between the domestic and in¬ 
ternational effects of curren t U.S. export con¬ 
trols on cryptography and the needs of business 
and user communities in an international 
economy. 

The need for reform of export controls was the 
number one topic at the workshop and perhaps the 
only area of universal agreement. Participants ex¬ 
pressed great concern that the current controls are 
impeding companies’ implementation of good se¬ 
curity in worldwide operations and harming U.S. 
firms’ competitiveness in the international mar¬ 
ketplace. More than one participant considered 
that what is really at stake is loss of U.S. leader¬ 
ship in the information technology industry. As 
one participant put it, the current system is “a mar¬ 
ket intervention by the government with unin¬ 
tended bad consequences for both government 
and the private sector.” 
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Several participants asserted that U.S. export 
controls have failed at preventing the spread of 
cryptography, because DES- and RSA-based en¬ 
cryption, among others, are available outside of 
this country. These considered that the only “suc¬ 
cess” of the controls has been to prevent major 
U.S. software companies from incorporating 
high-quality, easy-to-use, integrated cryptogra¬ 
phy in their products. 

The intense dissatisfaction on the part of the 
private sector with the lack of openness and 
progress in resolving cryptography-policy 
issues. 

Participants expressed frustration with the lack 
of a timely, open, and productive dialogue be¬ 
tween government and the private sector on cryp¬ 
tography issues and the lack of response by 
government to what dialogue has taken place. 48 
Many stressed the need for a genuine, open dia¬ 
logue between government and business, with 
recognition that business vitality is a legitimate 
objective. Participants noted the need for Con¬ 
gress to broaden the policy debate about cryptog¬ 
raphy, with more public visibility and more 
priority given to business needs and economic 
concerns. In the export control arena, Congress 
was seen as having an important role in getting 
government and the private sector to converge on 
some feasible middle ground (legislation would 
not be required, if export regulations were 
changed). Leadership and timeliness (“the prob¬ 
lem won’t wait”) were viewed as priorities, rather 
than more studies and delay. 

Many felt the information-policy branches of 
the government are unable to respond adequately 
to the current leadership vacuum; therefore, they 
felt that government should either establish a 
more effective policy system and open a construc¬ 
tive dialogue with industry or leave the problem to 
industry. 

The lack of public dialogue, visibility, and ac¬ 
countability, particularly demonstrated by the 
manner in which the Clipper chip was introduced 


and the EES promulgated, seemed to be a constant 
source of anger for both industry representatives 
and public interest groups. There were many con¬ 
cerns and frustrations about the role of the Nation¬ 
al Security Agency. Many participants suggested 
that this country desperately needs a new vision of 
“national security” that incorporates economic 
vitality. They consider that business strength is 
not part of NS A’s notion of “national security,” so 
it is not part of their mission. As one participant 
put it, “saying that ‘we all have to be losers’ on na¬ 
tional security grounds is perverse industrial 
policy.” 

The mismatch between the federal standards 
process for cryptography-related FIPS and 
private sector needs for exportable, cost-effec¬ 
tive safeguards. 

As noted above, many participants viewed ex¬ 
port controls as the single biggest obstacle to es¬ 
tablishing international standards for information 
safeguards, One participant also noted the pecu¬ 
liarity of picking a national standard (e.g., a FIPS 
like the DES) and then trying to restrict its use in¬ 
ternationally. 

The question of the availability of secure prod¬ 
ucts generated some disagreement over whether 
the market works or, at least, the extent to which it 
does and does not work. There was consensus that 
export controls and other government policies that 
segmented market demand were undesirable in¬ 
terventions. Though the federal government can 
use its purchasing power to significantly influence 
the market, most participants felt that this sort of 
market intervention would not be beneficial over¬ 
all. 

The mismatch between the intent of the Com¬ 
puter Security Act and its implementation. 

There was widespread support for the Comput¬ 
er Security Act of 1987, but universal frustration 
with its implementation. NIST, the designated 
lead agency for security standards and guidelines, 
was described as underfunded and extremely 


48 See ibid., pp. 11-13. 150-160, 174-179. 
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slow. There was also a general recognition that 
people had been complaining about NIST for a 
while, but nothing has happened as a result of 
these complaints. Some participants noted the im¬ 
portance of increased oversight of the Computer 
Security Act of 1987 (Public Law 100-235), as 
well as possible redirection of NIST activities 
(e.g., collecting information about what industry 
is doing, pointing out commonalities and how to 
interoperate, rather than picking out a “standard”). 

According to some participants, the govern¬ 
ment should get “its house in order” in the civilian 
agencies and place more emphasis on unclassified 
information security. There was a perceived need 
for timely attention, because the architecture and 
policy constructs of the international information 
infrastructure are being developed right now, but 
these are “being left to the technologists” due to 
lack of leadership. 

Several felt that the government has overem¬ 
phasized cryptography, to the exclusion of man¬ 
agement and problems like errors and dishonest 
employees that are not fully addressed by a 
“technology” focus. Participants considered that 
the real issue is management , not technology slo- 
ganism. According to participants, existing poli¬ 
cies [e.g., the previous version of OMB Circular 
A-130, Appendix III] attempt to mandate cost- 
based models, but the implementation is ineffec¬ 
tive. For example, after the Computer Security 
Act, NIST should have been in a position to help 
agencies, but this never happened due to lack of 
resources. Civil agencies lack resources, then 
choose to invest in new applications rather than 
spend on security. This is understandable when 
the observation that “nothing happens”—that is, 
no security incidents are detected—is an indicator 
of good security. Participants observed that, if in¬ 
spectors general of government agencies are per¬ 
ceived as neither rewarding or punishing, users 
get mixed signals and conclude that there is a mis¬ 
match between security postures and management 
commitment to security implementation. 

The distinction between security policies and 

guidelines for implementing these policies; 

and 


the need for technological flexibility in imple¬ 
menting security policies. 

Sound security policies are a foundation for 
good security practice. Importantly, these are not 
guidelines for implementation. Rather, they are 
“minimalist” directives that outline what must 
happen to maintain information security, but not 
how it must be achieved. 

One of the most important things about these 
policies is that they are consistent across the entire 
company; regardless of the department, informa¬ 
tion-security policies are considered universally 
applicable. The policies have to be designed in a 
broad enough fashion to ensure that all company 
cultures will be able to comply. (Implementation 
of these polices can be tailored to fit specific needs 
and business practices.) Broad policy outlines al¬ 
low information to flow freely between company 
divisions without increased security risk. 

The workshop discussion noted the importance 
of auditing security implementation against 
policy, not against implementation guidelines. 
Good security policies must be technology neu¬ 
tral , so that technology upgrades and different 
equipment in different divisions would not affect 
implementation. Ensuring that policies are 
technology neutral helps prevent confusing im¬ 
plementation techniques and tools (e.g., use of a 
particular type of encryption or use of a computer 
operating system with a certain rating) with policy 
objectives, and discourages “passive risk accep¬ 
tance” like mandating use of a particular tech¬ 
nology. This also allows for flexibility and 
customization. 

Workshop participants noted that, although the 
state of practice in setting security policy often has 
not lived up to the ideals discussed above, many 
companies are improving. At this point there are 
several road blocks frustrating more robust securi¬ 
ty for information and information systems. A pri¬ 
mary road block is cost. Many systems are not 
built with security in mind, so the responsibility 
falls on the end user and retrofitting a system with 
security can be prohibitively expensive. 
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The need for line-management accountability 
for, and commitment to, good security, as op¬ 
posed to “handing off” security to technology 
(i.e., hoping that a “technologicalfix ” will be a 
cure-all). 

The workshop discussion emphasized active 
risk acceptance by management and sound securi¬ 
ty policies as key elements of good information- 
security practice in the private sector. The concept 
of management responsibility and accountability 
as integral components of information security, 
rather than just “handing off’ security to technolo¬ 
gy, were noted as very important by several partic¬ 
ipants. There was general agreement that direct 
support by top management and upper-manage¬ 
ment accountability arc central to successful 
implementation of security policies. Many partic¬ 
ipants considered it vital that the managers under¬ 
stand active risk acceptance and not be insulated 
from risk. 

Most security managers participating in the 
workshop viewed training as vital to any success¬ 
ful information-security policy. Lack of training 
leads to simple errors potentially capable of de¬ 
feating any good security systemfor example, em¬ 
ployees who write their passwords on paper and 
tape it to their computers. Several participants 
knew of companies that have fallen into the 
technology trap and have designed excellent com¬ 
puter security systems without sufficiently em¬ 
phasizing training. There is a core of training 
material that is technology neutral and ubiquitous 
across the company. The necessity for impressing 
upon employees their role in information security 
was seen as paramount. 


ISSUE UPDATE 

Chapter 4 provides an update on executive-branch 
and private sector cryptography developments, 
business perspectives on government policies, 
congressional consideration of privacy issues, and 
government-wide guidance on information secu¬ 
rity in the federal agencies. The last section of 
chapter 4 discusses the implications of these de¬ 
velopments for congressional consideration of 
some of the issues and options identified in the 
1994 OTA report. 

I Government Cryptography Activities 

In mid-1994, the executive branch indicated an 
openness toward exploring alternative forms of 
key-escrow encryption (i.e., techniques not im¬ 
plementing the Skipjack algorithm specified in 
the Escrowed Encryption Standard (EES) for use 
in computer and video networks. 49 However, 
there has been no formal commitment to eventual¬ 
ly adopting any alternative to Skipjack in an es¬ 
crowed-encryption FIPS for computer data. 50 
Moreover, there has been no commitment to con¬ 
sider alternatives to the EES for telephony. 

Furthermore, there has been no backing away 
from the underlying Clinton Administration com¬ 
mitment to “escrowing” encryption keys. With 
tightly integrated, or “bound” escrowing, there is 
mandatory key deposit. In the future, there may be 
some choice of escrow agencies or registries, but 
at present, Clipper- and Capstone-chip keys are 
being escrowed within the Commerce and Trea¬ 
sury Departments. 51 The Clinton Administration 
has not indicated an openness toward optional de- 


49 For background, see appendix D of this background paper and OTA, op. cit., footnote 5, pp. 15-16, 171-174. The Escrowed Encryption 
Standard is described in box 2-3 of this paper. 

50 See box 2-3. The Capstone chip refers to a hardware implementation of the EES’s Skipjack algorithm, but for data communications. 
FORTEZZA (formerly TESSERA) is a PCMCIA card implementing Skipjack for data encryption, as well as the Digital Signature Standard (see 
box 2-2) and key-exchange functions. 

51 These chips implement the Skipjack algorithm for the EES and FORTEZZA applications, respectively. 
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posit of keys with registries, which OTA referred 
as “trusteeship” in the 1994 report (to distinguish 
it from the Clinton Administration’s concept of 
key escrowing being required as an integral paid of 
escrowed-encryption systems). 52 

The questions of whether or when there will be 
key-escrow encryption federal information proc¬ 
essing standards for unclassified data commu¬ 
nications and/or file encryption is still open. There 
is at present no FIPS specifying use of Skipjack 
for these applications. Implementation of key es¬ 
crowing or trusteeship for large databases (i.e., 
encryption for file storage, as opposed to commu¬ 
nications) has not been addressed by the govern¬ 
ment. Flowever, commercial key depositories or 
data-recovery centers are being proposed by sev¬ 
eral companies (see next section on private sector 
developments). 

Turning from encryption to digital signatures, 
acceptance and use of the new FIPS for digital sig¬ 
natures is progressing, but slowly. As the 1994 re¬ 
port detailed in its description of the evolution of 
the Digital Signature Standard, patent problems 
complicated the development and promulgation 
of the standard. 53 Patent-infringement uncertain¬ 
ties remain for the DSS, despite the government’s 
insistence that the DSS algorithm does not in¬ 
fringe any valid patents and its offer to indemnify 
vendors that develop certificate authorities for a 
public-key infrastructure. 54 

Plans to implement the DSS throughout gov¬ 
ernment are complicated by the relatively broad 


private sector use of a commercial alternative, the 
RSA signature system, and some agencies’ desire 
to use the RSA system instead of, or alongside, the 
DSS. Cost, as well as interoperability with the pri¬ 
vate sector, is an issue. The DSS can be imple¬ 
mented in hardware, software, or firmware, but 
NSA’s preferred implementation is in the “FOR- 
TEZZA” card. 

The FORTEZZA card (formerly called the 
TESSERA card) is a Personal Computer Memory 
Card Industry Association (PCMCIA) card. 55 
The FORTEZZA card is used for data commu¬ 
nications; it implements the Skipjack algorithm, 
as well as key-exchange and digital-signature 
functions. FORTEZZA applications include the 
Defense Departments’ Defense Message System. 
Per-workstation costs are significantly higher for 
the FORTEZZA card than for a software-based 
signature implementation alone. To use FOR¬ 
TEZZA, agencies must have—or upgrade to— 
computers with PCMCIA card slots, or must buy 
PCMCIA readers (about $125 each). 

According to NSA, current full costs for FOR¬ 
TEZZA cards are about $150 each in relatively 
small initial production lots; of this cost, about 
$98 is for the Capstone chip. About 3,000 FOR¬ 
TEZZA cards had been produced as of April 1995 
and another 33,000 were on contract. NSA hopes 
to award a large-scale production contract in fall 
1995 for 200,000 to 400,000 units. In these quan¬ 
tities, according to the agency, unit costs should be 


52 See OTA, op. cit., footnote 5, p. 171. 

53 See OTA, op. cit., footnote 1, appendix C, especially pp. 220-221. For a more recent account of the various lawsuits and countersuits 
among patent holders, licensers, and licensees, see Simson Garfinkle, PGP: Pretty Good Privacy (Sebastopol, CA: O’Reilly and Assoc., 1995), 
esp. ch. 6. 

54 F. Lynn McNulty et al., NIST, “Digital Signature Standard Update,” Oct. 11, 1994. The government offered to include an “authorization 
and consent” clause under which the government would assume liability for any patent infringement resulting from performance of a contract, 
including use of the DSS algorithm or public-key certificates by private parties when communicating with the government. See also OTA, op. 
cit., footnote 5, chapter 3. 

55 PCMCIA cards are slightly larger than a credit card, with a connector on one end that plugs directly into a standard slot in a computer (or 
reader). They contain microprocessor chips; for example, the FORTEZZA card contains a Capstone chip. 
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below the $100 per unit target established for the 
program. 56 Thus, the FORTEZZA production 
contract would be on the order of $20 million to 
$40 million. 

NIST is working on what is intended to become 
a market-driven validation system for vendors’ 
DSS products. This is being done within the 
framework of overall requirements developed for 
FIPS 140-1, “Security Requirements for Crypto¬ 
graphic Modules” (January 11, 1994). NIST is 
also developing a draft FIPS for “Cryptographic 
Service Calls” that would use relatively high-level 
application program interfaces (e.g., “sign” or 
“verify”) to call on any of a variety of crypto¬ 
graphic modules. The intention is to allow flexi¬ 
bility of implementation in what NIST recognizes 
is a “hybrid world.” Unfortunately, this work ap¬ 
pears to have been slowed due to the traditional 
scarcity of funds for such core security programs 
at NIST (see chapter 2 and the 1994 OTA report, 
pages 20 and 164). 

The 1996 Clinton Administration budget pro¬ 
posals reportedly do not specify funds for NIST 
work related to the DSS, or the EES. 57 However, 
according to the draft charter of the Government 
Information Technology Services Public-Key In¬ 
frastructure Federal Steering Committee, NIST 
will chair and provide administrative support for 
the Public-Key Infrastructure Federal Steering 
Commmittee that is being formed to provide guid¬ 
ance and assistance in developing an interoper¬ 
able, secure public-key infrastructure to support 


electionic commerce, electronic mail, and other 
applications. 

The Advanced Research Projects Agency 
(ARPA), the Defense Information Systems 
Agency (DISA), and NSA have agreed to estab¬ 
lish an Information Systems Security Research 
Joint Technology Office (JTO) to coordinate re¬ 
search programs and long range strategic planning 
for information systems security research and to 
expedite delivery of security technologies to 
DISA. Part of the functions of the JTO will be to: 

■ Encourage the U.S. industrial base to develop 
commercial products with built-in security to 
be used in DOD systems. Develop alliances 
with industry to raise the level of security in all 
U.S. systems. Bring together private sector 
leaders in information security to advise the 
JTO and build consensus for the resulting pro¬ 
gram. 

■ Identify areas for which standards need to be 
developed for information systems security. 

■ Facilitate the availability and use of NSA certi¬ 
fied cryptography within information systems 
security research programs. 58 

According to the Memorandum of Agreement es¬ 
tablishing JTO, its work is intended to improve 
DISA’s ability to safeguard the confidentiality, in¬ 
tegrity, authenticity, and availability of data in De¬ 
fense Department information systems, provide a 
“robust first line of defense” for defensive in¬ 
formation warfare, and permit electronic com- 


56 Bob Drake, Legislative Affairs Office, NSA, personal communication, Apr. 7, 1995. To make the apparent price of FORTEZZA cards 
more attractive to Defense Department customers in the short term, NSA is splitting the cost of the Capstone chip with them, so agencies can 
acquire the early versions of FORTEZZA for $98 apiece (ibid.). 

57 Kevin Power, “Fate of Federal DSS in Doubt,” Government Computer News, Mar. 6, 1995. The President’s budget does provide $100 
million to implement the digital wiretap legislation enacted at the close of the 103d Congress. See U.S. Congress, Office of Technology Assess¬ 
ment, Electronic Surveillance in Advanced Telecommunications Networks—Background Paper, forthcoming, spring 1995. 

58 “Memorandum of Agreement Between the Advanced Research Projects Agency, the Defense Information Systems Agency, and the Na¬ 
tional Security Agency Concerning the Information Systems Security Research Joint Technology Office,” Mar. 3,1995 (effective Apr. 2,1995). 
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merce between the Defense Department and its 
contractors. (See discussion of the Defense De¬ 
partment’s “Information Warfare” activities later 
in this chapter.) 

I Private Sector Cryptography 
Developments 59 

At the end of January 1995. AT&T Coip. and 
VLSI Technology. Inc., announced plans to devel¬ 
op an encryption microchip that would rival the 
Clipper and Capstone chips. The AT&T/VLSI 
chip will have the stronger, triple-DES imple¬ 
mentation of the Data Encryption Standard algo¬ 
rithm. 60 It is intended for use in a variety of 
consumer devices, including cellular - telephones, 
television decoder boxes for video-on-demand 
services, and personal computers. 61 The AT&T/ 
VLSI chips do not include key escrowing. Under 
current export regulations, they would be subject 
to State Department export controls. 

Industry observers consider this development 
especially significant as an indicator of the lack of 
market support for Clipper and Capstone chips be¬ 
cause AT&T manufactures a commercial product 
using Clipper chips (the AT&T Surity Telephone 
Device) and VLSI is the NS A contractor making 
the chips that Mykotronx programs (e.g., with the 
Skipjack algorithm and keys) to become Clipper 
and Capstone chips. 


The international banking and financial com¬ 
munities have long used encryption and authenti¬ 
cation methods based on the DES. Because these 
communities have a large installed base of DES 
technology; a transition to an incompatible (non- 
DES-based) new technology would be lengthy. 
The Accredited Standards Committee X9, which 
sets data security standards for the U.S. banking 
and financial services industries, reportedly an¬ 
nounced that it will develop new encryption stan¬ 
dards based on triple DES and will designate a 
subcommittee to develop technical standards for 
triple-DES applications. 62 

RSA Data Security, Inc., recently announced 
another symmetric encryption algorithm, called 
RC5. 63 According to the company, RC5 is faster 
than the DES algorithm, is suitable for hardware 
or software implementation, and has a range of 
user-selected security levels. Users can select key 
lengths ranging up to 2,040 bits, depending on the 
levels of security and speed needed. The RSA dig¬ 
ital signature system (see box 2-2 on page 48), 
from the same company, is the leading commer¬ 
cial rival to the Digital Signature Standard. RSA- 
based technology is also part of a new, proposed 
industry standard for protecting business transac¬ 
tions on the Internet. 64 

Another private sector standards group, the 
IEEE PI363 working group on public-key cryp- 


59 This section highlights selected government and commercial cryptography developments since publication of the 1994 OTA report. This 
is not a coomprehensive survey of commercial information-security products and proposals. Mention of individual companies or products is for 
illustrative purposes and/or identification only, and should not be interpreted as endorsement of these products or approaches. 

60 j n “triple DES,” the DES algorithm is used sequentially with three different keys, to encrypt, decrypt, then re-encrypt. Triple encryption 
with the DES offers more security than having a secret key that is twice as long as the 56-bit key specified in the FIPS. There is, however, no FIPS 
specifying triple DES. 

61 Jared Sandberg and Don Clark, “AT&T, VLSI Technology To Develop Microchips That Offer Data Security,” The Wall Street Journal, 
Jan. 31, 1995; see also Brad Bass, op. cit., footnote 19. 

62 CIPHER (Newsletter of the IEEE Computer Society’s TC on Security and Privacy), Electronic Issue No. 4, Carl Landwehr (ed.), Mar. 10, 
1995, available from (http://www.itd.nrl.navy.mil/ITD/5540/ieee/cipher/cipher-archive.html). 

63 Ronald L. Rivest, “The RC5 Encryption Algorithm,” Dr. Dobb’s Journal, January 1995, pp. 146, 148. 

64 Peter H. Lewis, “Accord Is Reached on a Common Security System for the Internet,” The New York Times, Apr. 11, 1995, p. D5. The 
proposed standard will be used to safeguard World Wide Web services. 
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tography, is developing a voluntary standard for 
“RSA, Diffie-Hellman, and Related Public-Key 
Cryptography” (see figure 2-5 on page 59). The 
group held a public meeting in Oakland, Califor¬ 
nia, in May 1995 to review a draft standard. 65 

Several companies have proposed alternative 
approaches to key-escrow encryption; these in¬ 
clude some 20 different alternatives. 66 Variously, 
these use published, unclassified encryption algo¬ 
rithms, thus potentially allowing software, as well 
as hardware, implementations. The commercial 
approaches would make use of commercial or pri¬ 
vate key-escrow systems, with data recovery ser¬ 
vices that are available to individuals and 
organizations, as well as to authorized law en¬ 
forcement agencies. 

A brief description of two of the commercial 
approaches is given in chapter 4, based on in¬ 
formation provided by Trusted Information Sys¬ 
tems (TIS) and Bankers Trust. The Bankers Trust 
system is hardware-based; the TIS system is soft- 
ware-based. Bankers Trust has proposed its sys¬ 
tem to the U.S. government and business 
community. The TIS system is under internal gov¬ 
ernment review to determine the sufficiency of the 
approach to meet national security and law en¬ 
forcement objectives. 

I Business Perspectives 

Representatives of major U.S. computer and soft¬ 
ware companies have recently reaffirmed the im¬ 
portance of security and privacy protections in the 
developing global information infrastructure 
(GII). 67 But, as the Computer Systems Policy 
Project’s “Perspectives on the Global Information 


Infrastructure” notes, there are strong and serious 
business concerns that government interests, es¬ 
pecially in the standards arena, could stifle com¬ 
mercial development and use of networks in the 
international arena. 

In June 1994, the Association for Computing 
Machinery (ACM) issued a report on the policy is¬ 
sues raised by introduction of the EES. The ACM 
report identified some key questions that need to 
be considered in reaching conclusions regarding: 

What cryptography policy best accommodates 
our national needs for secure communications and 
privacy, industry success, effective law enforce¬ 
ment, and national security ? 68 

The U.S. Public Policy Committee of the ACM 
(USACM) issued a companion set of recommen¬ 
dations, focusing on the need for: 

■ open forums for cryptography policy develop¬ 
ment, in which government, industry, and the 
public could participate; 

■ encryption standards that do not place U.S. 
manufacturers at a disadvantage in the global 
marketplace and do not adversely affect tech¬ 
nological development within the United 
States; 

■ changes in FIPS development, such as placing 
the process under the Administrative Proce¬ 
dures Act; 

■ withdrawal of the Clipper chip proposal by the 
Clinton Administration and the beginning of an 
open and public review of encryption policy; 
and 

■ development of technologies and institutional 
practices that will provide real privacy for fu- 


65 Ibid. Draft sections are available via anonymous ftp to rsa.com in the “pub/p 1 363 " directory. The working group's electronic mailing list 
is <pl363@rsa.com>; to join, send e-mail to <pl363-request@rsa.com>. 

66 See Dorothy E. Denning and Dennis Branstad, “A Taxonomy for Key Escrow Encryption,” forthcoming, obtained from the author (den- 
ning@cs.georgetown.edu); and Elizabeth Corcoran, “Three Ways To Catch a Code,” Washington Post, Mar. 16,1995, pp. B1, B12. The Corco¬ 
ran article also discusses the Hewlett-Packard Co.’s proposed “national flag card” approach to government-approved encryption. 

67 See Computer Systems Policy Project, Perspectives on the Global Information Infrastructure, (Washington, DC: February 1995). 

68 Susan Landau et al., Codes, Keys, and Conflicts: Issues in U.S. Crypto Policy (New York, NY: Association for Computing Machinery, 
Inc., June 1994). 
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ture users of the National Information Infra¬ 
structure. 69 

Also in 1994, the International Chamber of 
Commerce (ICC) issued its “ICC Position Paper 
on International Encryption Policy.” ICC noted 
the growing importance of cryptography in secur¬ 
ing business information and transactions on an 
international basis and, therefore, the significance 
of restrictions and controls on encryption methods 
as “artificial obstacles” to trade. ICC urged gov¬ 
ernments “not to adopt a restrictive approach 
which would place a particularly onerous burden 
on business and society as a whole.” 70 ICC’s posi¬ 
tion paper called on governments to: 1) remove 
unnecessary export and import controls, usage re¬ 
strictions, restrictive licensing arrangements and 
the like on encryption methods used in commer¬ 
cial applications; 2) enable network interoperabil¬ 
ity by encouraging global standardization; 3) 
maximize users’ freedom of choice; and 4) work 
together with industry to resolve barriers by joint¬ 
ly developing a comprehensive international 
policy on encryption. ICC recommended that 
global encryption policy be based on broad prin¬ 
ciples centered on openness and flexibility. 71 

The United States Council for International 
Business (USCIB) subsequently issued position 
papers on “Business Requirements for Encryp¬ 
tion” 72 and “Liability Issues and the U.S. Admin¬ 
istration’s Encryption Initiatives.” 73 The USCIB 
favored breaking down the “artificial banters” to 
U.S. companies’ competitiveness and ability to 
implement powerful security imposed by overly 
restrictive export controls. The Council called for 
international agreement on “realistic” encryption 
requirements, including: free choice of encryption 


algorithms and key management methods, public 
scrutiny of proposed standard algorithms, free ex¬ 
port/import of accepted standards, and flexibility 
in implementation (i.e., hardware or software). If 
key escrowing is to be used, the USCIB proposed 
that: 

■ a government not be the sole holder of the entire 
key except at the discretion of the user; 

■ the key-escrow agent make keys available to 
lawfully authorized entities when presented 
with proper, written legal authorizations (in¬ 
cluding international cooperation when the key 
is requested by a foreign government); 

■ the process for obtaining and using keys for 
wiretapping puiposes must be auditable; 

■ keys obtained from escrowing agents by law 
enforcement must be used only for a specified, 
limited time frame; and 

■ the owner of the key must (also) be able to ob¬ 
tain the keys from the escrow agent. 74 

The USCIB has also identified a number of dis¬ 
tinctive business concerns regarding the U.S. gov¬ 
ernment’s position on encryption and liability: 

■ uncertainty regarding whether the Clinton Ad¬ 
ministration might authorize strict government 
liability for misappropriation of keys, includ¬ 
ing adoption of tamper proof measures to ac¬ 
count for every escrowed unit key and family 
key (see box 2-3); 

■ the degree of care underlying design of Skip¬ 
jack, EES, and Capstone (given the govern¬ 
ment’s still-unresolved degree, if any, of 
liability); 

■ the confusion concerning whether the govern¬ 
ment intends to disclaim all liability in connec- 


69 U.S. Public Policy Committee of the ACM, “USACM Position on the Escrowed Encryption Standard,” June 1994. 

70 International Chamber of Commerce, “ICC Position Paper on International Encryption Policy,” Paris, 1994, pp. 2,3. See also United 
States Council for International Business, Private Sector Leadership: Policy Foundations for a National Information Infrastructure (Nil), July 
1994, p 5. 

71 Ibid., pp. 3-4. See also chapter 4 of the 1994 OTA report. 

72 United States Council for International Business, “Business Requirements for Encryption,” Oct. 10, 1994. 

73 United States Council for International Business, “Liability Issues and the U.S. Administration’s Encryption Initiatives,” Nov. 2, 1994. 

74 USCIB, op. cit., footnote 72, pp. 3-4. 
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tion with the EES and Capstone initiatives, and 
the extent to which family keys, unit keys, and 
law enforcement decryption devices will be ad¬ 
equately secured; and 

■ uncertainties regarding the liability of nongov¬ 
ernmental parties (e.g., chip manufacturers, 
vendors, and their employees) for misconduct 
or negligence. 75 

These types of concerns have remained unre¬ 
solved (see related discussion and options pres¬ 
ented in the 1994 OTA report, pages 16-18 and 
171-182). 

Liability issues are important to the develop¬ 
ment of electronic commerce and the underpin¬ 
ning institutional infrastructures, including (but 
not limited to) escrow agents for key-escrowed 
encryption systems and certificate authorities for 
public-key infrastructures. Widespread use of cer¬ 
tificate-based, public-key infrastructures will re¬ 
quire resolution and harmonization of liability 
requirements for trusted entities, whether these be 
federal certificate authorities, private certificate 
(or “certification”) authorities, escrow agents, 
banks, clearinghouses, value-added networks, or 
other entities. 76 

There is increasing momentum toward frame¬ 
works within which to resolve legal issues per¬ 
taining to digital signatures and to liability. For 
example: 

■ The Science and Technology Section of the 
American Bar Association’s Information Secu¬ 
rity Committee is drafting “Global Digital Sig¬ 
nature Guidelines” and model digital-signature 
legislation. 

■ With participation by the International Cham¬ 
ber of Commerce and the U.S. State Depart¬ 
ment, the United Nations Commission on 


International Trade Law has completed a Mod¬ 
el Law on electronic data interchange (EDI). 

■ Utah has just enacted digital signature legisla¬ 
tion. 77 

I Privacy Legislation 

In the 104th Congress, bills have been introduced 
to address the privacy-related issues of search and 
seizure, access to personal records, content of 
electronic information, drug testing, and im¬ 
migration and social security card fraud problems. 
In addition. Representative Cardiss Collins has re¬ 
introduced the “Individual Privacy Protection Act 
of 1995” (H.R. 184). H.R. 184 includes provi¬ 
sions to establish a Privacy Protection Commis¬ 
sion chai'gcd with ensuring the privacy rights of 
U.S. citizens, providing advisory guidance on 
matters related to electronic data storage, and pro¬ 
moting and encouraging the adoption of fair in¬ 
formation practices and the principle of collection 
limitation.. 

Immigration concerns and worker eligibility 
are prompting reexamination of social security 
card fraud and discussion over a national identifi¬ 
cation database. At least eight bills have been 
introduced in the 104th Congress to develop tam¬ 
per-proof or counterfeit-resistant social security 
cards (H.R. 560, H.R. 570, H.R. 756, H.R. 785) 
and to promote research toward a national identifi¬ 
cation database (H.R. 502, H.R. 195, S. 456, S. 
269). 

Four bills have been introduced modifying 
search and seizure limitations: H.R. 3, H.R. 666, 
S. 3, and S. 54. The “Exclusionary Rule Reform 
Act of 1995” (H.R. 666 and companion S. 54), 
which revises the limitations on evidence found 
during a search, passed the House on February 10, 


75 USCIB, op. cit., footnote 73, pp. 2-6. 

76 See ibid, for discussion of liability exposure, legal considerations, tort and contract remedies, government consent to be liable, and rec- 
ommendations and approaches to mitigate liability. 

77 Information on American Bar Association and United Nations activities provided by Michael Baum, Principal, Independent Monitoring, 
personal communication. Mar. 19, 1995. See also Michael S. Baum, Federal Certification Authority Liability and Policy: Law and Policy of 
Certificate-Based Public Key and Digital Signatures, NIST-GCR-94-654, NTIS Doc. No. PB94-191-202 (Springfield, VA: National Technical 
Information Service, 1994). 
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1995. Similar provisions have been included in 
crime legislation introduced in both houses, S. 3 
and H.R. 3. The Senate Committee on the Judicia¬ 
ry has held a hearing on Title V of S. 3, the provi¬ 
sions reforming the exclusionary rule. 

Also this session, legislation has been 
introduced increasing privacy protection by re¬ 
stricting the use or sale of lists collected by com¬ 
munication carriers (H.R. 411) and the U.S. Postal 
Service (H.R. 434), defining personal medical pri¬ 
vacy rights (H.R. 435, S. 7), detailing acceptable 
usage of credit report information (H.R. 561), and 
mandating procedures for determining the reli¬ 
ability of drug testing (H.R. 153). These bills es¬ 
tablish guidelines in specific areas, but do not 
attempt to address the overall challenges facing 
privacy rights in an electronic age. 

The “Family Privacy Bill” (H.R. 1271) passed 
the House on April 4, 1995. H.R. 1271, intro¬ 
duced by Representative Steve Horn on March 21, 
1995, is intended to provide parents the right to 
supervise and choose their children’s participation 
in any federally funded survey or questionnaire 
that involves intrusive questioning on sensitive is¬ 
sues. 78 Some have raised concerns about the bill 
on the grounds that it might dangerously limit lo¬ 
cal police authority to question minors and threat¬ 
en investigations of child abuse, or hinder doctors 
in obtaining timely patient information on chil¬ 
dren. 79 

In addition, the Office of Management and 
Budget recently published notice of draft privacy 
principles and draft security tenets for the national 
information infrastructure. 80 The draft privacy 
principles were developed by the Information In¬ 
frastructure Task Force’s Working group on Priva¬ 


cy and are intended to update and revise the Code 
of Fair Information Practices developed in the ear¬ 
ly 1970s and used in development of the Privacy 
Act of 1974. 

I Information-Security Policy 
Initiatives and Legislation 

The Defense Department’s “Information Warfare” 
activities address the opportunities and vulnera¬ 
bilities inherent in its (and the country’s) increas¬ 
ing reliance on information and information 
systems. The Department has a variety of In¬ 
formation Warfare activities ongoing in its ser¬ 
vices and agencies, the Office of the Secretary of 
Defense, and elsewhere. 81 The Department’s De¬ 
fensive Information Warfare program goals focus 
on technology development to counter vulnerabil¬ 
ities stemming from the Department’s growing 
dependence on information systems and the com¬ 
mercial information infrastructure (e.g., the pub¬ 
lic-switched network and the Internet). The 
Information Systems Security Research Joint 
Technology Office established by ARPA, DISA, 
and NS A (see above) will pursue research and de¬ 
velopment pursuant to these goals. 

The increasing prominence of Information 
Warfare issues has contributed to an increasing 
momentum for consolidating information-securi¬ 
ty authorities government-wide, thereby expand¬ 
ing the role of the defense and intelligence 
agencies for unclassified information security 
overall: 

. . . Protection of U.S. information systems is 
also clouded by legal restrictions put forth, for ex¬ 
ample, in the Computer Security Act of 1987. 


78 Representative Scott Mclnnis, Congressional Record , Apr. 4. 1995, p. H4126. 

79 Representative Cardiss Collins, Congressional Record , Apr. 4, 1995, p. H4126. 

80 Office of Management and Budget, “National Information Infrastructure: Draft Principles for Providing and Using Personal Information 
and Commentary,” Federal Register, vol. 60, No. 13, Jan. 20,1995, pp. 4362-4370. These were developed by the Privacy Working Group of the 
Information Policy Committee, Information Infrastructure Task Force (IITF). See also Office of Management and Budget, “Draft Security Te¬ 
nets for the National Information Infrastructure,” Federal Register, vol. 60, No. 28, Feb. 10,1995, p. 8100. These were developed by the Securi¬ 
ty Issues Forum of the IITF. 

81 See, e.g., “Report of the Defense Science Board Summer Study Task Force on Information Architecture for the Battlefield,” Office of the 
Under Secretary of Defense for Acquisition and Technology, October 1994. 
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Of concern to the Task Force is the fact that IW 
[Information Warfare] technologies and capabili¬ 
ties are largely being developed in an open com¬ 
mercial market and are outside of direct 
Government control. 82 

Such a consolidation and/or expansion would run 
counter to current statutory authorities and to 
OMB’s proposed new government-wide security 
and privacy policy guidance (see below). 

The Joint Security Commission 

In mid-1993, the Joint Security Commission was 
convened by the Secretary of Defense and the Di¬ 
rector of Central Intelligence to develop a “new 
approach to security that would assure the adequa¬ 
cy of protection within the contours of a security 
system that is simplified, more uniform, and more 
cost effective.” 83 The Joint Security Commis¬ 
sion’s report made recommendations across a 
comprehensive range of areas. 

The sections on information systems security 84 
and a security architecture for the future 85 are of 
special interest. In the context of the Commis¬ 
sion’s charter, they propose a unified security 
policy structure and authority for classified and 
unclassified information in the defense/intelli¬ 
gence community. 86 However, the report also rec¬ 
ommends a more general centralization of 
information security along these lines govern¬ 
ment-wide; the executive summary highlights the 
conclusion the security centralization within the 
defense/intelligence community described in the 


report should be extended government-wide. 87 
The report also recommends “establishment of a 
national level security policy committee to pro¬ 
vide structure and coherence to U.S. government 
security policy, practices, and procedures.” 88 

The Security Policy Board 

On September 16, 1994, President Clinton signed 
Presidential Decision Directive 29 (PDD-29). 
PDD-29, “Security Policy Coordination,” estab¬ 
lished a new structure, under the direction of the 
National Security Council (NSC), for the coor¬ 
dination, formulation, evaluation, and oversight 
of U.S. security policy. 89 According to the de¬ 
scription of PDD-29 provided to OTA by NSC, 
the directive designates the former Joint Security 
Executive Committee established by the Secre¬ 
tary of Defense and the Director of Central Intelli¬ 
gence as the Security Policy Board. 

The Security Policy Board (SPB) subsumes the 
functions of a number of previous national securi¬ 
ty groups and committees. The SPB members in¬ 
clude the Director of Central Intelligence, Deputy 
Secretary of Defense, Vice Chairman of the Joint 
Chiefs of Staff, Deputy Secretary of State, Under 
Secretary of Energy, Deputy Secretary of Com¬ 
merce, and Deputy Attorney General; plus one 
Deputy Secretary from “another non-defense-re - 
lated-agency” selected on a rotating basis, and one 
representative each from the OMB and NSC staff. 

The Security Policy Forum that had been estab¬ 
lished under the Joint Security Executive Com- 


82 Ibid., p. 52. 

83 Joint Security Commission, “Redefining Security: A Report to the Secretary of Defense and Director of Central Intelligence,” Feb. 28. 
1994 (quote from letter of transmittal). See also U.S. Congress, House of Representatives, Permanent Select Committee on Intelligence, “Intelli¬ 
gence Authorization Act for Fiscal Year 1994,” Rept. 103-162, Part I, 103d Congress, 1st session, June 29, 1993, pp. 26-27. 

84 Joint Security Commission, ibid., pp. 101-113. 

85 Ibid., pp. 127 et seq. 

86 Ibid., p. 105, first paragraph.; p. 110, recommendation; pp. 127-130. 

87 Ibid., p. viii, top. 

88 Ibid., p. 130. 

89 Although it is unclassified, PDD-29 has not been released. This discussion is based on a fact sheet provided to OTA by NSC; the fact sheet 
is said to be a “nearly verbatim text of the PDD,” with the only differences being “minor grammatical ones.” David S. Van Tassel (Director, 
Access Management, NSC), letter to Joan Winston (OTA), and enclosure, Feb. 16, 1995. 
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mittee was retained under the SPB. The forum is 
composed of senior representatives from over two 
dozen defense, intelligence, and civilian agencies 
and departments; the forum chair is appointed by 
the SPB chair. The Security Policy Forum func¬ 
tions are to: consider security policy issues raised 
by its members or others, develop security policy 
initiatives and obtain comments for the SPB from 
departments and agencies, evaluate the effective¬ 
ness of security policies, monitor and guide the 
implementation of security policies to ensure co¬ 
herence and consistency, and oversee application 
of security policies to ensure they are equitable 
and consistent with national goals. 90 

PDD-29 also established a Security Policy Ad¬ 
visory Board of five members from industry. This 
independent, nongovernmental advisory board is 
intended to advise the President on implementa¬ 
tion of the policy principles guiding the “new” 
formulation, evaluation, and oversight of U.S. se¬ 
curity policy, and to provide the SPB and the intel¬ 
ligence community with a “public interest” 
perspective. The SPB is authorized to establish in¬ 
teragency working groups as necessary to cany 
out its functions and to ensure interagency input to 
and coordination of security policy, procedures, 
and practices, with staffs to support the SPB and 
any other groups or fora established pursuant to 
PDD-29. 

PDD-29 was not intended to change or amend 
existing authorities or responsibilities of the 
members of the SPB, as “contained in the Nation¬ 
al Security Act of 1947, other existing laws or 
Executive Orders.” 91 PDD-29 does not refer spe¬ 
cifically to government information security 
policy, procedures, and practices, or to unclassi¬ 
fied information security government-wide. Nev¬ 
ertheless, the proposed detailed implementation 


of the directive with respect to information securi¬ 
ty, as articulated in the Security Policy staff report 
report, “Creating a New Order in U.S. Security 
Policy,” is a departure from the information secu¬ 
rity structure set forth in the Computer Security 
Act of 1987. The staff report appears to recognize 
this mismatch between its proposal and statutory 
authorities for unclassified information security, 
noting the Computer Security Act under informa¬ 
tion-security “actions required” to implement 
PDD-29. 92 

The SPB staff’s proposed “new order” for in¬ 
formation security builds on the Joint Security 
Commission’s analysis and recommendations to 
establish a “unifying body” government-wide. 93 
With respect to information security, the new SPB 
structure would involve organizing an Informa¬ 
tion Systems Security Committee (ISSC) charged 
with “coupling the development of policy for both 
the classified and the sensitive but unclassified 
communities” and a “transition effort” for conver¬ 
sion to the new structure. 94 

This “comprehensive structure” would be the 
new ISSC, that would be: 

. . . based on the foundation of the current 
NSTISSC [see appendix B of this background pa¬ 
per ] but will have responsibility for both the classi¬ 
fied and the sensitive but unclassified world. 

The ISSC would be jointly chaired at the SES 
[Senior Executive Service] or General Officer level 
by DOD and OMB. This new body would consist of 
voting representatives from each of the agencies/ 
departments currently represented on the 
NSTISSC and its two subcommittees, NIST and the 
civil agencies it represents, and other appropriate 
agencies/departments, such as DISA, which are 
currently not represented on the NSTISSC. This 


90 Ibid, (fact sheet). 

91 Ibid. 

92 U.S. Security Policy Board Staff, '‘Creating a New Order in U.S. Security Policy,” Nov. 21, 1994. p. 18. 

93 Ibid., p. 3. See Elizabeth Sikorovsky, “NSC Proposes To Shift Policy-Making Duties,” Federal Computer Week , Jan. 23.1995. pp. 1,45. 
See also Kevin Power, “Administration Floats New Information Security Policy,” Government Computer News, Jan. 23. 1995, p. 59. 

94 U.S. Security Policy Board Staff. op. cit., footnote 92, pp. II III. p. 15. 
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body would create working groups as needed to ad¬ 
dress topics of interest. 

The IS SC would eventually have authority over 
all classified and unclassified but sensitive sys¬ 
tems, and would report to through the [Security 
Policy] Forum and Board to the NSC. Thus, poli¬ 
cies would have the full force and authority of an 
NSC Directive, rather than the relatively “tooth¬ 
less” issuances currently emanating from the 
NSTISSC. NSA would continue to provide the sec¬ 
retariat to the new national INFOSEC structure, 
since the secretariat is a well-functioning, highly- 
efficient, and effective body. 

. . . A joint strategy would have to be devised for 
a smooth transition between the current and new 
structures, which would ensure that current mo¬ 
mentum is maintained and continuity preserved. In 
addition, a new definition must be developed for 
“national security information, ” and it must be de¬ 
termined how such information relates to the uncla- 
sified arena from a national security standpoint 
[emphasis added]. Issues such as voting in such a 
potentially unwieldy organization must also be re¬ 
solved. 95 

At this writing, the extent to which the SPB in- 
formation-security proposals, ISSC, and the de¬ 
velopment of a new definition of “national 
security information” have or have not been “en¬ 
dorsed” within the executive branch is unclear. 
Outside the executive branch, however, they have 
been met with concern and dismay reminiscent of 
reactions to NSDD-145 a decade ago (see chapter 
2 and appendix B). 96 Moreover, they run counter 
to the statutory agency authorities set forth in the 
104th Congress in the Paperwork Reduction Act 
of 1995 (see below), as well as in the Computer 


Security Act of 1987. At its March 23-24, 1995 
meeting, the Computer Systems Security and Pri¬ 
vacy Board that was established by the Computer 
Security Act issued Resolution 95-3, recommend¬ 
ing that the SPB await broader discussion of is¬ 
sues before proceeding with its plans “to control 
unclassified, but sensitive systems.” 

Concerns have also been expressed within the 
executive branch. The ISSC information security 
structure that would increase the role of the de¬ 
fense and intelligence communities in govern¬ 
mentwide unclassified information security runs 
counter to the Clinton Administration’s “basic as¬ 
sumptions” about free information flow and pub¬ 
lic accessibility as articulated in the 1993 revision 
of OMB Circular A-130, “Management of Federal 
Information Resources.” 97 

Moreover, some senior federal computer secu¬ 
rity managers have expressed concern about what 
they consider premature implementation of the 
SPB staff report’s proposed centralization of in¬ 
formation security functions and responsibilities. 
In a January 11, 1995, letter to Sally Katzen, Di¬ 
rector of the Office of Information and Regulatory 
Affairs, Office of Management and Budget (re¬ 
leased March 23, 1995), the Steering Committee 
of the Federal Computer Security Program Man¬ 
ager’s Forum 98 indicated “unanimous disagree¬ 
ment” with the Security Policy Board’s (SPB) 
proposal and urged OMB to “take appropriate ac¬ 
tion to restrict implementation of the SPB report 
to only classified systems.” 99 This type of restric¬ 
tion appears to have been incorporated in the pro¬ 
posed revision to Appendix III of OMB Circular 
A-130 (see below). 


95 Ibid., pp. 17-18. See appendix B of this paper and OTA, op. cit., footnote 5, pp. 132-148 for discussion of NSDD-145. the intent of the 
Computer Security Act of 1987, and NSTISSC. 

96 See Neil Munro, “White House Security Panels Raise Hackles,” Washington Technology, Feb. 23, 1995, pp. 6, 8. 

97 OMB Circular A-130—Revised, June 25, 1993, Transmittal Memorandum No. 1, sec. 7. 

98 The Federal Computer Security Program Manager’s Forum is made up of senior computer security managers for civilian agencies, in¬ 
cluding the Departments of Commerce, Health and Human Services, Justice, and Transportation. The January 11, 1995, letter to Sally Katzen. 
Director of the Office of Information and Regulatory Affairs, Office of Management and Budget, was signed by Lynn McNulty, Forum Chair 
(National Institute of Standards and Technology) and Sadie Pitcher, Forum Co-chair (Department of Commerce). Text of letter taken from the 
online EPIC Alert, vol. 2.05, Mar. 27, 1995. 

99 Ibid. 
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In March and April 1995, OTA invited the Se¬ 
curity Policy Board staff to comment on draft 
OTA text discussing information-security central¬ 
ization, including the Joint Security Commission 
report, PDD-29, and the SPB staff report. OTA re¬ 
ceived SPB staff comments in early May 1995, as 
this background paper was in press. According to 
the Security Policy Board staff director, informa¬ 
tion systems security policy is a “work in progress 
in its early stages” for the SPB and the staff report 
was intended to be a “strawman” stalling point for 
discussion. Moreover, according to the SPB staff, 
“recognizing the sensitivity and complexity of In¬ 
formation Systems Security policy, the ISSC was 
not one of the committees which was established, 
nor was a transition team formed.” 100 In order to 
provide as much information as possible for con¬ 
sideration of information security issues, includ¬ 
ing the SPB staff perspective, OTA has included 
the SPB staff comments in box 1-3. 

The Paperwork Reduction Act of 1995 

The Paperwork Reduction Act was reauthorized 
in the 104th Congress. The House and Senate ver¬ 
sions of the Paperwork Reduction Act of 1995 
(H.R. 830 and S.244) both left existing agency au¬ 
thorities under the Computer Security Act of 1987 
unchanged. 101 The Paperwork Reduction Act of 
1995 (Public Law 104-13) was reported on April 
3, 1995, 102 passed in both Houses on April 6, 
1995, and signed by President Clinton on May 22, 
1995. 


Among its goals, the Paperwork Reduction Act 
of 1995 is intended to make federal agencies more 
responsible and publicly accountable for informa¬ 
tion management. With respect to safeguarding 
information, the act seeks to: 

. . . ensure that the creation, collection, mainte¬ 
nance, use, dissemination, and disposition of in¬ 
formation by or for the Federal Government is 
consistent with applicable laws, including laws re¬ 
lating to— 

(A) privacy and confidentiality, including sec¬ 
tion 552a of Title 5; 

(B) security of information, including the Com¬ 
puter Security Act of 1987 (Public Law 
100-235); and 

(C) access to information, including section 
552 of Title 5. 103 

With respect to privacy and security, the Paper¬ 
work Reduction Act of 1995 provides that the Di¬ 
rector of OMB shall: 

1. develop and oversee the implementation of 
policies, principles, standards, and guide¬ 
lines on privacy, confidentiality, security, 
disclosure, and sharing of information col¬ 
lected or maintained by or for agencies; 

2. oversee and coordinate compliance with 
sections 552 and 552a of title 5, the Comput¬ 
er Security Act of 1987 (40 U.S.C. 759 note), 
and related information management laws; 
and 

3. require Federal agencies, consistent with the 
Computer Security Act of 1987 (40 U.S.C. 

59 note), to identify and afford security 


100 p e t er £> Saderholm (Director, Security Policy Board Staff), memorandum for Joan D. Winston and Miles Ewing (OTA), SPB 095-95, 
May 4, 1995. 

101 Senator William V. Roth, Jr., Congressional Record, Mar. 6. 1995, p. S3512. 

102 U.S. Congress, House of Representatives, “Paperwork Reduction Act of 1995—Conference Report to Accompany S.244,” H. Rpt. 
104-99, Apr. 3.1995. As the “Joint Explanatory Statement of the Committee of the Conference” (ibid., pp. 27-39) notes, the 1995 act retains the 
legislative history of the Paperwork Reduction Act of 1980. Furthermore, the definition of "information technology” in the 1995 act is intended 
to preserve the exemption for military and intelligence information technology that is found in current statutory definitions of “automatic data 
processing." The 1995 act accomplishes this by referring to the so-called Warner Amendment exemptions to the Brooks Act of 1965 and. thus, 
to section 111 of the Federal Property and Administrative Services Act (ibid., pp. 28-29). See also discussion of the Warner Amendment exemp¬ 
tions from the FIPS and the Computer Security Act in appendix B of this background paper. 

103 Ibid., sec. 3501(8). The act amends chapter 35 of title 44 U.S.C. 
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protections commensurate with the risk and 
magnitude of the harm resulting from the 
loss, misuse, or unauthorized access to or 
modification of information collected or 
maintained by or on behalf of an agency. 104 

The latter requirement for cost-effective securi¬ 
ty implementation and standards is tied to the 
roles of the Director of NIST and the Administra¬ 
tor of General Services in helping the OMB to: 

(A) develop and oversee the implementation of 
polices, principles, standards, and guide¬ 
lines for information technology functions 
and activities of the Federal Government, 
including periodic evaluations of major in¬ 
formation systems; and 

(B) oversee the development and implementa¬ 
tion of standards under section 111(d) of the 
Federal Property and Administrative Ser¬ 
vices Act of 1949 (40 U.S.C. 759(d)). 105 

Federal agency heads are responsible for ensuring 
that their agencies shall: 

1. implement and enforce applicable policies, 
procedures, standards, and guidelines on 
privacy, confidentiality, security, disclosure, 
and sharing of information collected or 
maintained by or for the agency; 

2. assume responsibility and accountability for 
compliance with and coordinated manage¬ 
ment of sections 552 and 552a of title 5, the 
Computer Security Act of 1987 (40 U.S.C. 
759 note), and related information manage¬ 
ment laws; and 

3. consistent with the Computer Security Act 
of 1987 (40 U.S.C. 59 note), identify and af¬ 
ford security protections commensurate 
with the risk and magnitude of the harm 
resulting from the loss, misuse, or unau¬ 
thorized access to or modification of in¬ 


formation collected or maintained by or on 
behalf of an agency. 106 

Proposed Revision of Appendix III 
of OMB Circular A-130 

At this writing, OMB had just completed the pro¬ 
posed revision of Appendix III. The proposed re¬ 
vision is intended to lead to improved federal 
information-security practices and to make fulfill¬ 
ment of Computer Security Act and Privacy Act 
requirements more effective generally, as well as 
with respect to data sharing and secondary uses. 
As indicated above, the Paperwork Reduction Act 
of 1995 has affirmed OMB's government-wide 
authorities for information security and privacy. 

The new, proposed revision of Appendix III 
(“Security of Federal Automated Information”) 
will be key to assessing the prospect for improved 
federal information security practices. The pro¬ 
posed revision was posted for public comment on 
March 29, 1995. According to OMB, the pro¬ 
posed new government-wide guidance: 

... is intended to guide agencies in securing in¬ 
formation as they increasingly rely on an open and 
interconnected National Information Infrastruc¬ 
ture. It stresses management controls such as indi¬ 
vidual responsibility, awareness and training, and 
accountability, rather than technical controls . . . 

The proposal would also better integrate securi¬ 
ty into program and mission goals, reduce the need 
for centralized reporting of paper security plans, 
emphasize the management of risk rather than its 
measurement, and revise government-wide securi¬ 
ty responsibilities to be consistent with the Com¬ 
puter Security Act. 107 

According to OMB, the proposed new security 
guidance reflects the significant differences in ca- 


104 Ibid., sec. 3504(g). The OMB Director delegates authority to administer these functions to the Administrator of OMB’s Office of In- 
formation and Regulatory Affairs. 

1()5 Ibid., section 3504(h)(1). See also “Joint Explanatory Statement of the Committee of the Conference,” ibid., pp. 27-29. 

106 Ibid., section 3506(g). 

107 office of Management and Budget, “Security of Federal Automated Information,” Proposed Revision of OMB Circular No. A-130 Ap¬ 
pendix III (transmittal memorandum), available via World Wide Web at http://csrc.ncsl.nist.gov/secplcy as <al30app3.txt>. 
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BOX 1-3: Security Policy Board Staff Perspectives on Information-Security Issues 


OTA note: This material presents Security Policy Board staff views on information security issues and 
the SPB staff report. It was excerpted from SPB staff comments to OTA and has been edited for length. 

... [T]he general area of Information Systems Security presents us all with one of the most difficult and 
controversial aspects of security policy. Because of this, there has been a great deal of recent analysis and 
activity in the area of Information Systems Security policy involving the Security Policy Board (SPB), the 
Security Policy Forum (SPF), and out supporting Staff. Because of the fast pace of recent events, and the 
fact that for the SPB/SPF, Information Systems Security policy is a “work in progress” in its early stages, we 
have not done the best job in getting the word out to the community beyond the 26 agencies and depart¬ 
ments that are represented in the SPB on the current status of our Information Systems Security-related 
activities. [The OTA background paper] may provide an excellent vehicle for presenting a balanced view of 
Executive Branch analysis and activity in this critical policy area. 

... The [section above on information-security policy initiatives] begins by accurately noting that net¬ 
work security issues are of great concern, and then suggests that DOD activity under the name of “In¬ 
formation Warfare” (IW) is raising awareness of threats to networks, and is contributing to the momentum 
for consolidating Information Systems Security authorities government-wide, thereby increasing the role of 
the defense and intelligence agencies. While that may be true to some extent, the draft is silent on other 
reasons why there may be a “momentum” for at least considering the advisability of consolidating some 
aspects of government Information Systems Security policymaking, e.g., the increasing internetworking 
across the “classified' and “unclassified” communities. Others may argue that the splitting of Information 
Systems Security responsibilities by Public Law 100-235 simply isn’t working to provide the level of sys¬ 
tems security both communities need—failing for many of the same reasons the PDD-24 failed when it 
attempted to split Communications Security (COMSEC) authorities along similar lines. However, it is not the 
role of the SPB/SPF Staff to take a position on these issues, but rather to act as an “honest broker” within 
the Executive Branch to ensure that all aspects of security policy receive an informed, balanced review. In 
pursuing this role, we have recognized the relationship of defensive IW to Information Systems Security 
policy, but do not see it as the only, or even the primary, driver of whatever momentum exists to consoli¬ 
date Executive Branch Information Systems Security responsibilities. Many of the issues surrounding the 
“consolidation” question-e. g., efficient use of limited government resources—have no trace of the De¬ 
fense/Intelligence flavor of DOD Information Warfare activities... 

[OTA’S description] of PDD-29 and its organization creations is mostly accurate although you err in im¬ 
plying that the structure is DOD and Intelligence Community oriented. Actually, quite the opposite is true. In 
fact, if OTA were to be challenged to develop a senior level government-wide board to serve as a “fair 
court” to adjudicate information systems security and other security policy issues, you would quite likely 
develop an entity very similar if not the same as the SPB. The majority of the SPB itself comes from the civil 
agencies. .. [T]he very important Security Policy Forum (SPF) includes among its 26 members the Depart¬ 
ments of Commerce, Energy, Justice, State, Treasury, Transportation, and representatives from OMB, Na¬ 
tional Aeronautics and Space Administration, Nuclear Regulatory Commission, Office of Personnel Man¬ 
agement, General Services Administration, and Federal Emergency Management Agency. Again, the 
majority of the SPF membership is from the civil agencies. Quite frankly, we find it ironic that your draft 
gives significant credence to negative comments about the SPB efforts credited to representatives of Com¬ 
merce and the OMB when both the Deputy Secretary of Commerce and the Deputy Director of the OMB sit 
on the SPB and have been active participants in the SPB deliberations to date. 
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BOX 1-3 (cont’d.): Security Policy Board Staff Perspectives on Information-Security Issues 


In PDD-29, the President observed, “We require a new security process based on sound threat analysis 
and risk management practices. A process which can adapt our security policies, practices and proce¬ 
dures as the economic, political and military challenges to our national interests continue to evolve.” The 
President further charged the SPB to conduct a review of all of our nation’s security policies, practices and 
procedures and make recommendations for needed change after such proposals have been coordinated 
with all US. departments and agencies affected by such decisions. 

At the first SPB meeting on 27 September 1994, the SPB Staff was charged with starting a government¬ 
wide dialogue on the various elements of security policy by developing a “strawman” proposal. The Staff 
attempted to start this by publishing the “New Order” paper, which simply contained proposals [emphasis 
in original] for how the government might more effectively address the various security disciplines, as rec¬ 
ommended by the Joint Security Commission (JSC). Many of the Staff recommendations were “no brain- 
ers. ” In the field of personnel security, for example, the government had already consolidated its efforts 
into one entity. In essence, the SPB Staff attempted to begin the dialogue by suggesting the most simple 
structure possible to address government-wide security policy. The SPB and SPF subsequently acted on 
some of the report’s proposals and established transition teams and committees for four of the six commit¬ 
tees proposed in the report. A fifth will be established in mid-May. However, recognizing the sensitivity and 
complexity of Information Systems Security policy, the ISSC was not one of the committees which was es¬ 
tablished, nor was a transition team formed. Those who view the establishment of the other committees as 
somehow transforming the Staff Report into official administration policy are mistaken, and it is unfortunate 
that so many have chosen to misrepresent the Staff Report. I can assure you that the SPB, SPF, and Staff 
have not presented the “New Order” report as anything other than an early effort at establishing a starting 
point for serious dialogue on overall security policy. 

The idea of an ISSC with government-side scope has, as fully expected, met with opposition from vari¬ 
ous parties for various reasons. It is our goal to facilitate an informed discussion of the information systems 
security issues facing our nation, and to have that informed discussion occur at the appropriate levels 
within the government. Our review to date has focused almost exclusively on the ever growing area where 
the classified community and the unclassified community intersect. Therein are any number of government 
owned systems which may be considered critical to the safety and security of our nation and its people: 
systems such as the Federal Election System, air traffic control and those that control our nation’s power 
grid, for example. It has generally been assumed that the private sector, to the extent possible, will devel¬ 
op the needed security for these systems. This may be true, but the question remains that if an “Oklahoma 
City” like incident occurs in one or more of these systems, who will our nation, the Congress, and our Presi¬ 
dent turn to. To that end, we framed the “scope” issue for the SPF, which, in turn, raised the issue at the 24 
April 1995 meeting of the SPB. The outcome of that meeting was direction by the SPB to its member agen¬ 
cies to attempt development of Terms of Reference for an interagency group to study these issues and 
report back to the SPB. The SPB Staff has, therefore, scheduled a meeting to begin that process which 
[took] place on 4 May 1995. In keeping with our efforts to be the “honest broker,” the Staff has invited all 
member agencies, Office of Science and Technology Policy and other interested departments and agen¬ 
cies representing the widely divergent points of view with regard to this subject. 

(continued) 
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BOX 1-3 (cont’d.): Security Policy Board Staff Perspectives on Information-Security Issues 


In taking this initiative, the Deputy Secretaries that comprise the SPB recognize that they may be sub¬ 
ject to criticism. However, their concerns about taking positive action to avoid catastrophe in any number 
of these critical systems was best summed up when one observed, “Shame on us if we don't at least try!” 

The SPB, SPF, and Staff have not and never will propose that any information systems security actions 
will be taken which are contrary to law, government regulations, or directives. It does not necessarily fol¬ 
low, however, that issues cannot be explored, that ideas cannot be considered, or that new approaches to 
difficult security problems cannot be explored which are outside the context of preexisting policies, laws, 
regulations, and organizational structures. It is entirely possible that what was appropriate in 1987 may not 
be completely adequate in 1995. Information technology has advanced manyfold since then; the National 
Information Infrastructure has developed and the information systems security challenges facing the clas¬ 
sified and unclassified communities have become more similar, Indeed, the very reason for establishing 
the JSC was to develop new approaches to security that would “assure the adequacy of protection within 
the contours of a security system that is simplified , more uniform, and more cost effective [emphasis in 
original], As referenced earlier in PDD-29, the President directed that “The SPB will be the principal mecha¬ 
nism for reviewing and proposing to the NSC legislative initiatives and executive orders pertaining to U.S. 
security policy, procedures, and practices. . .“ If an informed dialogue within the government, across the 
Executive and Legislative Branches, leads to a common sense view to make Information Systems Security 
policy in a manner different from the way it is currently done, then laws, policies, regulations, and organiza¬ 
tional structures could certainly be adjusted to accomplish national Information Systems Security goals. 
Again, it is our role on the SPB/SPF Staff to facilitate that informed dialogue. 

SOURCE. Excerpted from Peter 0. Saderholm (Director, Security Policy Board Staff), memorandum to Joan D. Winston and Miles 
Ewing (OTA), May 4, 1995, 


pabilities, risks, and vulnerabilities of the present 
computing environment, as opposed to the rela¬ 
tively closed, centralized processing environment 
of the past. Today’s processing environment is 
characterized by open, widely distributed in¬ 
formation-processing systems that are intercon¬ 
nected with other systems within and outside 
government and by an increasing dependence of 
federal agency operations on these systems. 
OMB’s “federal information technology world” 
encompasses over 2 million individual worksta¬ 
tions (e.g., PCs), but only some 25,000 medium 
and large computers. Accordingly, a major fo¬ 
cus of OMB’s new guidance is on end users and 
decentralized information-processing systems— 


and the information-processing applications they 
use and support. 

According to OMB, the proposed revision of 
Appendix 111 stresses management controls (such 
as individual responsibility, awareness, and train¬ 
ing) and accountability, rather than technical con¬ 
trols. OMB also considers that the proposed 
security appendix would better integrate security 
into agencies’ program and mission goals, reduce 
the need for centralized reporting of paper security 
plans, emphasize the management of risk rather 
than its measurement, and revise government- 
wide security responsibilities to be consistent 
with the Computer Security Act. 109 


108 Ed Springer, OMB, personal communication, Mar. 23, 1995. 
109 Office of Management and Budget, op. cit., footnote 107. 
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OMB’s proposed new security appendix: 

. . . proposes to re-orient the Federal computer 
security program to better respond to a rapidly 
changing technological environment. It establishes 
government-wide responsibilities for Federal com¬ 
puter security and requires Federal agencies to 
adopt a minimum set of management controls. 

These management controls are directed at indi¬ 
vidual information technology users in order to re¬ 
flect the distributed nature of today’s technology. 
For security to be most effective, the controls must 
be a part of day-to-day operations. This is best ac¬ 
complished by planning for security not as a sepa¬ 
rate activity, but as part of overall planning. 

“Adequate security” is defined as “security 
commensurate with the risk and magnitude of harm 
from the loss, misuse, or unauthorized access to or 
modification of information.” This definition ex¬ 
plicitly emphasizes the risk-based policy for cost- 
effective security established by the Computer 
Security Act. 110 

The new guidance assigns the Security Policy 
Board responsibility for (only) “national security 
policy coordination in accordance with the ap¬ 
propriate Presidential directive [e.g., PDD 
29] 111 With respect to national security informa¬ 
tion: 

Where an agency processes information which 
is controlled for national security reasons pursuant 
to an Executive Order or statute, security measures 
required by appropriate directives should be in¬ 
cluded in agency systems. Those policies, proce¬ 
dures, and practices will be coordinated with the 
U.S. Security Policy Board as directed by the Presi¬ 
dent. 112 

Otherwise, the proposed OMB guidance assigns 
government-wide responsibilities to agencies that 
is “consistent with the Computer Security Act.” 
These agencies include the Department of Com¬ 
merce, through NIST; the Department of Defense, 


through NSA; the Office of Personnel Manage¬ 
ment; the General Services Administration; and 
the Department of Justice. 113 

A complete analysis of the proposed revision to 
Appendix III is beyond the scope of this back¬ 
ground paper. In brief, the proposed new guidance 
reflects a fundamental and necessary shift in em¬ 
phasis from securing automated information sys¬ 
tems to safeguarding automated information 
itself. It seeks to accomplish this through: 

■ controls for general support systems (including 
hardware, software, information, data, applica¬ 
tions, and people) that share common function¬ 
ality and are under the same direct management 
control; and 

■ controls for major applications (that require 
special attention due to their mission-critical 
nature). 

For each type of control, OMB seeks to ensure 
managerial accountability by requiring manage¬ 
ment officials to authorize in writing , based on re¬ 
view of implementation of the relevant security 
plan, use of the system or application. For general 
support systems, OMB specifies that use should 
be re-authorized at least every three years. Simi¬ 
larly, major applications must be authorized be¬ 
fore operating and reauthorized at least every three 
years thereafter. For major applications, manage¬ 
ment authorization implies accepting the risk of 
each system used by the application. 114 

This type of active risk acceptance and account¬ 
ability, coupled with review and reporting require¬ 
ments, is intended to result in agencies ensuring 
that adequate resources are devoted to implement¬ 
ing “adequate security.” Every three years (or 
when significant modifications are made), agen¬ 
cies must review security controls in systems and 
major applications and correct deficiencies. De¬ 
pending on the severity, agencies must also con- 


11(1 Ibid., p. 4. 

111 Ibid., p. 15. 

112 Ibid., pp. 3-4. 

113 Ibid., pp. 14-16. 

114 Ibid., pp. 2-6. 
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sider identifying a deficiency in controls pursuant 
to the Federal Manager’s Financial Accountabil¬ 
ity Act. Agencies are required to include a sum¬ 
mary of their system security plans and major 
application security plans in the five-year plan re¬ 
quired by the Paperwork Reduction Act. 

IMPLICATIONS FOR 
CONGRESSIONAL ACTION 

Appendix D of this paper, based on chapter 1 of 
the 1994 OTA report on information security and 
privacy, reviews the set of policy options in that 
report. OTA identified policy options related to 
three general policy areas: 

1. national cryptography policy, including feder¬ 
al information processing standards and export 
controls; 

2. guidance on safeguarding unclassified in¬ 
formation in federal agencies; and 

3. legal issues and information security, includ¬ 
ing electronic commerce, privacy, and intel¬ 
lectual property. 

In all, OTA identified about two dozen possible 
options. The need for openness , oversight , and 
public accountability —given the broad public 
and business impacts of these policies—runs 
throughout the discussion of possible congres¬ 
sional actions. During its follow-on work, OTA 
found that recent and ongoing events have rele¬ 
vance for congressional consideration of policy 
issues and options identified in the 1994 report, 
particularly in the first two areas noted above. 

In OTA’s view, two key questions underlying 
consideration of options addressing cryptography 
policy and unclassified information security with¬ 
in the federal government are: 

1. Flow will we as a nation develop and maintain 
the balance among traditional “national securi¬ 
ty” (and law enforcement) objectives and other 
aspects of the public interest, such as economic 
vitality, civil liberties, and open government? 

2. What are the costs of government efforts to 
control cryptography and who will bear them? 

Some of these costs—for example, the incremen¬ 
tal cost of requiring a “standard” solution that is 


less cost-effective than the “market” alternative in 
meeting applicable security requirements—may 
be relatively easy to quantify, compared with oth¬ 
ers. But none of these cost estimates will be easy 
to make. Some costs may be extremely difficult to 
quantify, or even to bound—for example, the im¬ 
pact of technological uncertainties, delays, and 
regulatory requirements on U.S. firms’ abilities to 
compete effectively in the international market¬ 
place for information technologies. Ultimately, 
however, these costs are all borne by the public, 
whether in the form of taxes, product prices, or 
foregone economic opportunities and earnings. 

The remainder of this chapter discusses pos¬ 
sible congressional actions related to cryptogra¬ 
phy policy and government information security, 
in the context of the policy issues and options 
OTA identified in the 1994 report. These options 
can be found in appendix D of this background pa¬ 
per and pp. 16-20 of the 1994 report. For the read¬ 
er’s convenience, the pertinent options are 
discussed in boxes 1-4 through 1-7 in this chapter. 

I Cryptography Policy and 
Export Controls 

In the 1994 study and its follow-on work, OTA has 
observed that many of the persistent concerns sur¬ 
rounding the Clinton Administration’s escrowed- 
encryption initiative focus on whether key-escrow 
encryption will become mandatory for govern¬ 
ment agencies or the private sector, if nones- 
crowed encryption will be banned, and/or if these 
actions could be taken without legislation. Other 
concerns still focus on whether or not alternative 
forms of encryption would be available that would 
allow private individuals and organizations the 
option of depositing keys (or not) with one or 
more third-party trustees—at their discretion (see 
pp. 8-10,14-18,171-182 of the 1994 OTA report). 

Congressional Review of 
Cryptography Policy 

OTA noted that an important outcome of a con¬ 
gressional review of national cryptography policy 
would be the development of more open processes 
to determine how cryptography will be deployed 
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BOX 1-4: Congressional Review of Cryptography Policy 


OTA concluded that information to support a congressional policy review of cryptography is out of 
phase with implementation. Therefore, OTA noted that: 

OPTION: Congress could consider placing a hold on further deployment of key-escrow encryp¬ 
tion, pending a congressional policy review. 

More open processes would build trust and confidence in government operations and leadership. More 
openness would allow diverse stakeholders to understand how their views and concerns were being bal¬ 
anced with those of others, in establishing an equitable deployment of these technologies, even when 
some of the specifics of the technology remain classified. More open processes would also allow for public 
consensus-building, providing better information for use in congressional oversight of agency activities. 
Toward these ends, OTA noted that: 

OPTION: Congress could address the extent to which the current working relationship between 
the National Institute of Standards and Technology and National Security Agency will be a satisfac¬ 
tory part of this open process, or the extent to which the current arrangements should be reevalu¬ 
ated and revised. 

Another important outcome of a broad policy review would be a clarification of national information- 
policy principles in the face of technological change: 

OPTION: Congress could state its policy as to when the impacts of a technology (like cryptogra¬ 
phy) are so powerful and pervasive that legislation is needed to provide sufficient public visibility 
and accountability for government actions. 

SOURCE: Office of Technology Assessment, 1995; based on Information Security and Privacy in Network Environments (OTA- 
TCT-606, September 1994). 


throughout society, including development of the 
public-key infrastructures and certification autho¬ 
rities that will support electronic delivery of gov¬ 
ernment services and digital commerce. 

In 1993, Congress asked the National Research 
Council to conduct a major study that would sup¬ 
port a broad review of cryptography and its de¬ 
ployment; the results are expected to be available 
in 1996. The NRC study should be valuable in 
helping Congress to understand the broad range of 
technical and institutional alternatives. However, 
if implementation of the EES and related technol¬ 
ogies continues at the current pace, OTA has noted 
that key-escrow encryption may already be em¬ 
bedded in information systems before Congress 
can act on the NRC report. 

Therefore, OTA’s options for congressional 
consideration (see box 1-4) included an option to 
place a hold on further deployment of escrowed 
encryption within the government, pending a con¬ 
gressional review, as well as options addressing 


open policy implementation, and public visibility 
and accountability. These are still germane, espe¬ 
cially given the NSA’s expectation of a large-scale 
investment in FORTEZZA cards and the likeli¬ 
hood that nondefense agencies will be encouraged 
by NS A to join in adopting FORTEZZA. 

There has been very little information from the 
Clinton Administration as to the current and pro¬ 
jected costs of the escrowed-encryption initiative, 
including costs of the current escrow agencies for 
Clipper and Capstone chips and total expenditures 
anticipated for deployment of escrowed-encryp¬ 
tion technologies. (NSA has indicated that a FOR¬ 
TEZZA procurement contract on the order of $20 
million to $40 million may be awarded in fall 
1995.) 

Export Controls 

Reform of the current export controls on cryptog¬ 
raphy was certainly the number one topic at the 
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BOX 1-5: Export Controls on Cryptography 


As part of a broad national cryptography policy, OTA noted that Congress may wish to periodically ex¬ 
amine export controls on cryptography, to ensure that these continue to reflect an appropriate balance be¬ 
tween the needs of signals intelligence and law enforcement and the needs of the public and business 
communities. This examination would take into account changes in foreign capabilities and foreign avail¬ 
ability of cryptographic technologies. 

Information from an executive branch study of the encryption market and export controls that was 
promised by Vice President Gore should provide some near-term information. The Department of Com¬ 
merce and the National Security Agency (NSA) are assessing the economic impact of U.S. export controls 
on the U.S. computer software industry; as part of this study, NSA is determining the foreign availability of 
encryption products. The study is scheduled to be delivered to the National Security Council deputies by 
July 1, 1995. 

OTA noted that the scope and methodology of the export-control studies that Congress might wish to 
use in the future may differ from those used in the executive-branch study. Therefore: 

OPTION: Congress might wish to assess the validity and effectiveness of the Clinton Administra¬ 
tion’s studies of export controls on cryptography by conducting oversight hearings, by undertaking 
a staff analysis, or by requesting a study from the Congressional Budget Office. 

SOURCE: Off Ice of Technology Assessment, 1995: based on Information Security and Privacy in Network Environments (OTA- 
TCT-606, September 1994). 


December 1994 OTA workshop. More generally, 
the private sector’s priority in this regard is indi¬ 
cated by the discussion of the industry statements 
of business needs above. Legislation would not be 
required to relax controls on cryptography, if this 
were done by revising the implementing regula¬ 
tions. However, the Clinton Administration has 
previously evidenced a disinclination to relax 
controls on robust cryptography, except perhaps 
for certain key-escrow encryption products. 1 ' 3 

The Export Administration Act is to be reau¬ 
thorized in the 104th Congress. The issue of ex¬ 
port controls on cryptography may arise during 
consideration of export legislation, or if new ex¬ 
port procedures for key-escrow encryption prod¬ 
ucts are announced, and/or when the Clinton 
Administration’s market study of cryptography 
and controls is completed this summer (see box 
1-5). 


Aside from any consideration of whether or not 
to include cryptography provisions in the 1995 ex¬ 
port administration legislation, Congress could 
advance the convergence of government and pri¬ 
vate sector interests into some “feasible middle 
ground” through hearings, evaluation of the Clin¬ 
ton Administration’s market study, and by encour¬ 
aging a more timely, open, and productive 
dialogue between government and the private sec¬ 
tor (see pages 11-13, 150-160, 174-179 of the 
1994 OTA report.) 

Responses to Escrowed 
Encryption Initiatives 

The 1994 OTA report recognized that Congress 
has a near-term role to play in determining the ex¬ 
tent to which—and how—the EES and other es¬ 
crowed-encryption systems will be deployed in 


15 See appendix C of this backgroud paper, especially footnote 10 and accompanying text. 
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BOX 1-6: Congressional Responses to Escrowed-Encryption Initiatives 


In responding to current escrowed-encryption initiatives like the Escrowed Encryption Standard (EES), 
and in determining the extent to which appropriated funds should be used in implementing key-escrow 
encryption and related technologies, OTA noted that: 

OPTION: Congress could address the appropriate locations of the key-escrow agents, particularly 
for federal agencies, before additional investments are made in staff and facilities for them. Public 
acceptance of key-escrow encryption might be improved-but not assured-by an escrowing system 
that used separation of powers to reduce perceptions of the potential for misuse. 

With respect to current escrowed-encryption initiatives like the EES, as well as any subsequent key-es¬ 
crow encryption initiatives (e.g., for data communications or file encryption), and in determining the extent 
to which appropriated funds should be used in implementing key-escrow encryption and related technolo¬ 
gies, OTA noted that: 

OPTION: Congress could address the issue of criminal penalties for misuse and unauthorized 
disclosure of escrowed key components. 

OPTION: Congress could consider allowing damages to be awarded for individuals or organiza¬ 
tions who were harmed by misuse or unauthorized disclosure of escrowed key components. 

SOURCE: Office of Technology Assessment, 1995; based on Information Security and Privacy in Network Environments (OTA- 
TCT-606, September 1994). 


the United States. These actions can be taken 
within a long-term, strategic framework. Con¬ 
gressional oversight of the effectiveness of policy 
measures and controls can allow Congress to re¬ 
visit these issues as needed, or as the conse¬ 
quences of previous decisions become more 
apparent. 

The Clinton Administration has stated that it 
has no plans to make escrowed encryption manda¬ 
tory, or to ban other forms of encryption. But, ab¬ 
sent legislation, these intentions are not binding 
for future administrations and also leave open the 
question of what will happen if the EES and re¬ 
lated technologies do not prove acceptable to the 
private sector. Moreover, the executive branch 
may soon be using the EES and/or related es¬ 
crowed-encryption technologies (e.g., FORTEZ- 
ZA) to safeguard-among other things—large 
volumes of private and proprietary information. 

For these reasons, OTA concluded that the EES 
and other key-escrowing initiatives are by no 
means only an executive branch concern. The 
EES and any subsequent escrowed-encryption 
standards (e.g., for data communications in com¬ 
puter networks, or for file encryption) also war¬ 


rant congressional attention because of the public 
funds that will be spent in deploying them. More¬ 
over, negative public perceptions of the EES and 
the processes by which encryption standards are 
developed and deployed may erode public confi¬ 
dence and trust in government and, consequently, 
the effectiveness of federal leadership in promot¬ 
ing responsible safeguard use. Therefore, OTA 
identified options addressing location of escrow 
agents, as well as criminal penalties and civil lia¬ 
bilities for misuse or unauthorized disclosure of 
escrowed key components (see box 1-6). These 
are still germane, and the liability issues are even 
more timely, given recent initiatives by the in¬ 
ternational legal community and the states. 

i Safeguarding Unclassified Information 
in the Federal Agencies 

The need for congressional oversight of federal in¬ 
formation security and privacy is even more ur¬ 
gent in a time of government reform and 
streamlining. When the role, size, and structure of 
the federal agencies are being reexamined, it is im¬ 
portant to take into account the additional in- 
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formation security and privacy risks incurred in 
downsizing and the general lack of commitment 
on the part of top agency management to safe¬ 
guarding unclassified information. 

A major problem in the agencies has been lack 
of top management focus on, not to mention re¬ 
sponsibility and accountability for, information 
security. As the 1994 OTA report noted: 

The single most important step toward imple¬ 
menting proper information safeguards for net¬ 
worked information in a federal agency or other 
organization is for top management to define the 
organization’s overall objectives and a security 
policy to reflect those objectives. Only top man¬ 
agement can consolidate the consensus and apply 
the resources necessary to effectively protect net¬ 
worked information. For the federal government, 
this means guidance from OMB, commitment from 
top agency management, and oversight by Con¬ 
gress. (p. 7) 

All too often, agency managers have regarded 
information security as “expensive overhead” that 
could be skimped on, deferred, or foregone in fa¬ 
vor of other expenditures (e.g., for new computer 
hardware and applications). Any lack of priority 
and resources for safeguarding information is in¬ 
creasingly problematic as we move toward in¬ 
creased secondary use of data, data sharing across 
agencies, and decentralization of information 
processing and databases. If this mindset were 
permitted to continue during agency downsizing 
and program consolidation, the potential—and 
realized—harms from “disasters waiting to hap¬ 
pen” can be much greater. (See pages 1-8, 25-31, 
and 40-43 of the 1994 OTA report.) For example, 
without proper attention to information security, 
staffing changes during agency restructuring and 
downsizing can increase security risks (due to un¬ 
staffed or understaffed security functions, reduc¬ 
tions in security training and implementation, 
large numbers of disgruntled former employees, 
etc.). 

OTA’s ongoing work has spotlighted important 
elements of good information-security practice in 
the private sector, including active risk acceptance 
by line management. The concept of management 
responsibility and accountability as integral com¬ 


ponents of information security, rather than just 
“handing off’ security to technology, is very im¬ 
portant. 

Sound security policies as a foundation for 
practice are essential; these should be technology 
neutral. Technology-neutral policies specify what 
must be done, not how to do it. Because they do 
not prescribe implementations, technology-neu¬ 
tral policies are longer lived. They are not so easi¬ 
ly obsoleted by changes in technology or business 
practices; they allow for local customization of 
implementations to meet operational require¬ 
ments. Once these are in place, security imple¬ 
mentation should be audited against policy, not 
against implementation guidelines. This helps 
prevent confusing implementation techniques and 
tools (e.g., use of a particular' type of encryption or 
use of an computer operating system with a certain 
rating) with policy objectives, and discourages 
“passive risk acceptance” like mandating use of a 
particular technology. This also allows for flexi¬ 
bility and customization. 

In the federal arena, however, more visible en¬ 
ergy seems to have been focused on debates over 
implementation tools—that is, federal informa¬ 
tion processing standards like the Data Encryption 
Standard, Digital Signature Standard, and Es¬ 
crowed Encryption Standard—than on formulat¬ 
ing enduring, technology-neutral policy guidance 
for the agencies. 

Direction of Revised OMB Guidance 

In the 1994 report, OTA identified the need for the 
revised version of the security appendix (Appen¬ 
dix III) of OMB Circular A-130 to adequately ad¬ 
dress problems of managerial responsibility and 
accountability, insufficient resources devoted to 
information security, and overemphasis on tech¬ 
nology, as opposed to management. In particular, 
OTA noted the importance of making agency line 
management (not just “information security offi¬ 
cers”) accountable for information security and 
ensuring that privacy and other policy objectives 
are met. Moreover, OTA noted that the proposed 
new OMB guidance would have to provide suffi¬ 
cient incentives—especially in times of budget 
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cuts—to ensure that agencies devote adequate re¬ 
sources to safeguarding information. Similarly, 
the OMB guidance would have to ensure that in¬ 
formation safeguards are treated as an integral 
component when systems are designed or modi¬ 
fied. 

The proposed revision to Appendix III of OMB 
Circular A-130, as discussed above, shows prom¬ 
ise for meeting these objectives. OMB’s proposed 
guidance is intended to incorporate critical ele¬ 
ments of the following: considering security as in¬ 
tegral (rather than an add-on) to planning and 
operations, active risk acceptance, line manage¬ 
ment responsibility and accountability, and focus 
on management and people rather than technolo¬ 
gy. Taken as a whole, these elements are intended 
to provide sufficient incentives for agency man¬ 
agements to devote adequate resources to securi¬ 
ty; the review and reporting requirements offer 
disincentives for inadequate security. Moreover, 
if implemented properly, the new OMB approach 
can make significant progress in the ultimate goal 
of tracking and securing the information itself, as 
it is gathered, stored, processed, and shared 
among users and applications. 

However, OMB’s twofold approach is some¬ 
what abstract and a significant departure from ear¬ 
lier, “computer security” guidance. Therefore, 
congressional review and oversight of OMB's 
proposed revisions to Appendix III, as suggested 
in the 1994 OTA report (see box 1-7), would be 
helpful in ensuring that Congress, as well as feder¬ 
al agencies and the public, understand the new in- 
formation-security guidance and how OMB 
intends for its new approach to be implemented. 

This congressional review and oversight might 
also provide additional guidance on how NIST’s 
security activities might best be refocused to meet 
federal information-security objectives. For ex¬ 
ample, in addition to Commerce’s (i.e., NIST’s) 
traditional responsibilities for security standards 
and training and awareness, the new Appendix III 
assigns Commerce responsibilities for providing 


agencies with guidance and assistance concerning 
effective controls when systems are intercon¬ 
nected, coordinating incident response activities 
to promote information-sharing regarding inci¬ 
dents and related vulnerabilities, and (with De¬ 
fense Department technical assistance) evaluating 
new information technologies to assess their secu¬ 
rity vulnerabilities and apprising agencies of these 
in a timely fashion. 116 

Locus of Authority 

Another reason for the importance and timeliness 
of congressional oversight of governmentwide in- 
formation-security policy guidance is that there is 
renewed momentum for extending the defense/in¬ 
telligence community’s centralization of informa¬ 
tion-security responsibilities throughout the civil 
agencies as well. If initiatives such as the Informa¬ 
tion Systems Security Committee structure pres¬ 
ented in the Security Policy Boar'd staff report 
come to fruition, information-security responsibi¬ 
lities for both the civilian agencies and the de¬ 
fense/intelligence agencies would be merged. 

An overarching issue that must be resolved by 
Congress is where federal authority for safeguard¬ 
ing unclassified information in the civilian agen¬ 
cies should reside and, therefore, what needs to be 
done concerning the substance and implementa¬ 
tion of the Computer Security Act of 1987. If Con¬ 
gress retains the general premise of the act—that 
responsibility for unclassified information securi¬ 
ty in the civilian agencies should not be placed 
within the defense/intelligence community—then 
vigilant oversight and clear direction will be need¬ 
ed to ensure effective implementation, including 
assigning and funding a credible focal point(s) for 
unclassified information security (see discussion 
of OMB Appendix III above and also pp. 19-20 of 
the 1994 OTA report). 

Without doubt, leadership and expertise are 
needed for better, more consistent safeguarding of 
unclassified information government-wide. But it 


116 


OMB. op. cit., footnote 82, p. 7. 
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BOX 1-7: Safeguarding Information in Federal Agencies 


Congress has an even more direct role in establishing the policy guidance within which federal agen¬ 
cies safeguard information, and in oversight of agency and Office of Management and Budget measures to 
implement information security and privacy requirements. The new, proposed revision of Appendix III (“Se¬ 
curity of Federal Automated Information’’) of OMB Circular A-130 is intended to lead to improved federal 
information-security practices and to make fulfillment of Computer Security Act and Privacy Act require¬ 
ments more effective generally, as well as with respect to data sharing and secondary uses. 

The options presented below are in the context of the 1994 report and the previous version of Appendix 
III. However, OTA expects that congressional oversight and analysis as indicated below will remain useful 
for understanding OMB's new guidance and assessing its potential effectiveness. OTA noted that, after the 
revised Appendix III of OMB Circular A-130 issued: 

OPTION: Congress could assess the effectiveness of the OMB’s revised guidelines, including im¬ 
provements in implementing the Computer Security Act’s provisions regarding agency security 
plans and training, in order to determine whether additional statutory requirements or oversight 
measures are needed. 

This might be accomplished by conducting oversight hearings, undertaking a staff analysis, and/or re¬ 
questing a study from the General Accounting Office. However, the effects of OMB’s revised guidance may 
not be apparent for some time after the revised Appendix III is issued. 

Therefore, a few years may pass before GAO is able to report government-wide findings that would be 
the basis for determining the need for further revision or legislation. In the interim: 

OPTION: Congress could gain additional insight through hearings to gauge the reaction of agen¬ 
cies, as well as privacy and security experts from outside government, to OMB’s revised guidelines. 

Oversight of this sort might be especially valuable for agencies that are developing major new informa¬ 
tion systems, in the course of its oversight and when considering the direction of any new legislation, OTA 
noted that: 

OPTION: Congress could ensure that agencies include explicit provisions for safeguarding in¬ 
formation assets in any information-technology planning documents. 


is not clear that there are no workable alternatives 
to centralizing government-wide information-se¬ 
curity responsibilities under the defense/intelli¬ 
gence community. Proposals to do so note current 
information-security deficiencies; however, many 
of these can be attributed to lack of commitment to 
and funding for establishment of an alternative 
source of expertise and technical guidance for the 
civilian agencies. For example, the “efficiency” 
arguments (see below) made in the Joint Security 
Commission report and the Security Policy Board 
staff report for extending the responsibilities of 
the defense/intelligence community to encompass 
government-wide security for classified and un¬ 
classified information capitalize on the vacuum in 
leadership and expertise created by chronic un¬ 


derfunding of the designated civilian agency—at 
present, NIST. (See pp. 13-16, 20, 138-150, and 
182-183 of the OTA report.) 

Proposals for centralizing security responsibi¬ 
lities for both classified and unclassified informa¬ 
tion government-wide offer efficiency arguments 
to the effect that: 

1. security policies, practices, and procedures (as 
well as technologies) for unclassified informa¬ 
tion are for the most part spin-offs from the 
classified domain; 

2. the defense and intelligence agencies are expert 
in classified information security; and there¬ 
fore 
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BOX 1-7 (cont’d.): Safeguarding Information in Federal Agencies 


OPTION: Congress could ensure that agencies budget sufficient resources to safeguard informa¬ 
tion assets, whether as a percentage of information-technology modernization and/or operating 
budgets, or otherwise. 

OPTION: Congress could ensure that the Department of Commerce assigns sufficient resources 
to the National Institute of Standards and Technology to support its Computer Security Act respon¬ 
sibilities, as well as NET’S other activities related to safeguarding information and protecting priva¬ 
cy in networks. 

Regarding NIST’s computer-security budget, OTA did not determined the extent to which additional 
funding is needed, or the extent to which additional funding would improve the overall effectiveness of 
NEST's information-security activities. Additional resources, whether from overall increases in NIST's budget 
or otherwise, could enhance NIST's technical capabilities, enable it to be more proactive, and hence be 
more useful to federal agencies and to industry. OTA found that NIST activities regarding standards and 
guidelines related to cryptography are a special case, however. 

Increased funding alone will not be sufficient to ensure NIST's technological leadership or its fulfillment 
of the “balancing” role as envisioned by the Computer Security Act of 1987. With respect to cryptography, 
OTA concluded that national security constraints set forth in executive branch policy directives appear to 
be binding. These constraints have resulted, for example, in the closed processes by which the FIPS 
known as the Escrowed Encryption Standard (Clipper) was developed and implemented. 

Increased funding could enable NIST to become a more equal partner to the National Security Agency, 
at least in deploying (if not developing) cryptographic standards. But, if NIST/NSA processes and out¬ 
comes are to reflect a different balance of national security and other public interests, or more openness, 
than has been evidenced over the past five years, OTA concluded that clear policy guidance and oversight 
(not just funding) will be needed. 

SOURCE” Office of Technology Assessment, 1995; based on Information Security and Privacy in Network Environments (OTA- 
TCT-606, September 1994). 


3. the unclassified domain can best be served by 
extending the authority of the defense/intelli¬ 
gence agencies. 

The validity of the “spin-off’ assumption about 
unclassified information security is questionable. 
There are real questions about NSA’s ability to 
place the right emphasis on cost-effectiveness, as 
opposed to absolute effectiveness, in flexibly de¬ 
termining the most appropriate means for safe¬ 
guarding unclassified information. Due to its 
primary mission in securing classified informa¬ 
tion, NSA’s traditional culture tends toward a 
standard of absolute effectiveness, not trading off 
cost and effectiveness. By contrast, the Computer 


Security Act of 1987, the Paperwork Reduction 
Act of 1995, and the new, proposed revision of 
OMB Appendix 111 all require agencies to identify 
and employ cost-effective safeguards, for ex¬ 
ample: 

With respect to privacy and security, the Direc¬ 
tor [of OMB] shall. . . require Federal agencies, 
consistent with the Computer Security Act of 1987 
(940 U.S.C. 759 note) security protections com¬ 
mensurate with the risk and magnitude of the harm 
resulting from the loss, misuse, or unauthorized ac¬ 
cess to or modification of information collected or 
maintained by or on behalf of an agency. 117 


“Paperwork Reduction Act of 1995” (S. 244), section 3504(g)(3), Mar. 7, 1995, Federal Record, p. S3557. 
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Moreover, the current state of government securi¬ 
ty practice for unclassified information has been 
depressed by the chronic shortage of resources for 
NIST’s computer security activities in fulfillment 
of its government-wide responsibilities under the 
Computer Security Act of 1987. Since enactment 
of the Computer Security Act, there has been no 
serious (i.e., adequately funded and properly 
staffed), sustained effort to establish a center of in- 
formation-security expertise and leadership out¬ 
side the defense/intelligence communities. 

Even if the efficiency argument is attractive, 
Congress would still need to consider whether the 
gains would be sufficient to overcome the con¬ 
comitant decrease in “openness” in information- 
security policymaking and implementation, 
and/or whether the outcomes would fall at an ac¬ 
ceptable point along the “efficiency-openness” 
possibility frontier. In the area of export controls 
on cryptography, for example, there is substantial 
public concern with the current tradeoff between 
the needs of the defense/intelligence and the busi¬ 
ness/user communities. With respect to informa¬ 
tion-security standards and guidelines, there has 
been continuing concern with the lack of openness 
and accountability in policies formulated and im¬ 
plemented under executive order, rather than 
through the legislative process. It would be diffi¬ 
cult to formulate a scenario in which increasing 
the defense/intelligence community’s authority 
government-wide would result in more openness 
or assuage public concerns. (In the 1980s, con¬ 
cerns over NSDD-145’s placement of govern¬ 
mental authority for unclassified information 


security within the defense/intelligence commu¬ 
nity led to enactment of the Computer Security 
Act of 1987.) 

Oversight of the implementation of the Comput¬ 
er Security Act is also important to cryptography 
policy considerations. The cryptography-related 
FIPS still influence the overall market and the de¬ 
velopment of recent FIPS (e.g., the DSS and EES) 
demonstrates a mismatch between the intent of the 
act and its implementation by NIST and NSA (see 
pp. 160-183 of the 1994 OTA report). The attrib¬ 
utes of these standards do not meet most users’ 
needs, and their deployment would benefit from 
congressional oversight, both in the strategic con¬ 
text of a policy review and as tactical response to 
the Clinton Administration’s escrowed-encryp¬ 
tion initiative (see pp. 16-20 of the OTA report). 

If the Computer Security Act is revisited, Con¬ 
gress might wish to redirect NIST’s activities 
away from “picking technologies” for standards 
(i.e., away from developing product-oriented 
FIPS like the EES) and toward providing federal 
agencies with guidance on: 

■ the availability of suitable commercial technol¬ 
ogies, 

■ interoperability and application portability, and 

■ how to make best use of existing hardware and 

software technology investments. 

Also, targeting NIST’s information-security acti¬ 
vities toward support of OMB’s proposed guid¬ 
ance (with its focus on end users and individual 
workstations) might enable NIST to be more ef¬ 
fective despite scarce resources. 


Overview of the 
1994 OTA Report 
on Information 
Security 
and Privacy 


T his chapter highlights the importance of information secu¬ 
rity and privacy issues, explains why cryptography poli¬ 
cies are so important, and reviews policy findings and 
options from the September 1994 OTA report Informa¬ 
tion Security and Privacy in Network Environmen ts. Chapter 3 re¬ 
views the December 1994 OTA workshop and identifies key 
points that emerged from the workshop discussion, particularly 
export controls and the international business environment, fed¬ 
eral cryptography policy, and information-security “best prac¬ 
tices.” Chapter 4 presents implications for congressional action, 
in light of recent and ongoing events. 

This background paper is a companion and supplement to the 
September 1994 OTA report and is intended to be used in con¬ 
junction with that report. For the reader’s convenience, however, 
pertinent technical and institutional background material, drawn 
from the September 1994 report and updated where appropriate, 
is included in appendices B (“Federal Information Security and 
the Computer Security Act”), C (“U.S. Export Controls on Cryp¬ 
tography”), and D (“Summary of Issues and Options from the 
1994 OTA Report”). 

INFORMATION SECURITY AND PRIVACY 
IN A NETWORKED SOCIETY 

Information technologies are transforming the ways in which we 
create, gather, process, and share information. Rapid growth in 
computer networking is driving many of these changes; electron¬ 
ic transactions and electronic records are becoming central to ev¬ 
erything from business to health care. Government connectivity 
is also growing rapidly in scope and importance. Within the feder- 
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al government, effective use of information 
technologies and networks is central to govern¬ 
ment restructuring and reform. 1 

The transformation being brought about by net¬ 
working brings with it new concerns for the secu¬ 
rity of networked information and for our ability 
to maintain effective privacy protections in net¬ 
worked environments. 2 Unless these concerns can 
be resolved, they threaten to limit networking’s 
full potential in terms of both participation and 
usefulness. Therefore, information safeguards 
(countermeasures) are achieving new promi¬ 
nence. 3 Appropriate safeguards for the networked 
environment must account for—and anticipate— 
technical, institutional, and social changes that in¬ 
creasingly shift responsibility for security to the 
end users. 

Computing power used to be isolated in large 
mainframe computers located in special facilities; 
computer system administration was centralized 
and carried out by specialists. In today’s net¬ 
worked environment, computing power is de¬ 
centralized to diverse users who operate desktop 
computers and who may have access to comput¬ 
ing power and data at remote locations. Distrib¬ 
uted computing and open systems can make every 
user essentially an “insider.” In such a decentral¬ 


ized environment, responsibility for safeguarding 
information is distributed to the users, rather than 
remaining the purview of system specialists. The 
increase in the number and variety of network ser¬ 
vice providers also requires that users take respon¬ 
sibility for safeguarding information, rather than 
relying on intermediaries to provide adequate 
protection. 4 

The new focus is on safeguarding the informa¬ 
tion itself as it is processed, stored, and trans¬ 
mitted. This contrasts with older, more static or 
insulated concepts of “document” security or 
“computer” security. In the networked environ¬ 
ment, we need appropriate rules for handling 
proprietary, copyrighted, and personal informa¬ 
tion—and tools with which to implement them. 5 
Increased interactivity means that we must also 
deal with transactional privacy, as well as prevent 
fraud in electronic commerce and ensure that safe¬ 
guards are integrated as organizations streamline 
their operations and modernize their information 
systems. 

REVIEW OF THE 1994 OTA REPORT 

In September 1994, the Office of Technology As¬ 
sessment released the report Information Security 


1 See U.S. Congress. Office of Technology Assessment, Making Government Work: Electronic Delivery of Government Sendees , OTA- 
TCT-578 (Washington, DC: U.S. Government Printing Office, September 1993). See also Elena Varon, “Senate Panel Takes up IT Management 
Issues,” Federal Computer Week, Feb. 6,1995, p. 6; and Charles A. Bowsher, Comptroller General of the United States, “Government Reform: 
Using Reengineering and Technology To Improve Government Performance,” GAO/T-OCG-95-2, testimony presented before the Committee 
on Governmental Affairs, U.S. Senate, Feb. 2, 1995. 

2 For example, measures to streamline operations via information technology require careful attention both to technical safeguards and to 
related institutional measures, such as employee training and awareness. Similarly, computer networks allow more interactivity, but the result¬ 
ing transactional data may require additional safeguards to protect personal privacy. 

3 See Michael Neubarth et al., “Internet Security (Special Section),” Internet World, February 1995, pp. 31-72. See also Russell Mitchell, 
“The Key to Safe Business on the Net,” and Amy Cortese et al., “Warding Off the Cyberspace Invaders,” Business Week, Mar. 13,1995, pp. 86, 
92-93. 

4 The trend is toward decentralized, distributed computing, rather than centralized, mainframe computing. Distributed computing is rela¬ 
tively informal and “bottom up,” compared with mainframe computing, and systems administration may be less rigorous. See U.S. Congress, 
Office ofTechnology Assessment, Information Security and Privacy in Network Environments, OTA-TCT-606 (Washington, DC: U.S. Govern¬ 
ment Printing Office, September 1994), pp. 3-5,25-32. Available from OTA Online via anonymous file transfer protocol (ftp://otabbs.ota.gov/ 
pub/information.security/) or World Wide Web (http://www.ota.gov). 

5 See ibid., chapter 3. “Security” technologies like encryption can be used to help protect privacy and the confidentiality of proprietary 
information; some, like digital signatures, could be used to facilitate copyright-management systems. 
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and Privacy in Net\\>ork Environments . 6 The re¬ 
port was prepared in response to a request by the 
Senate Committee on Governmental Affairs and 
the House Subcommittee on Telecommunications 
and Finance that OTA study the changing needs 
for protecting unclassified information and for 
protecting the privacy of individuals. 7 The request 
for the study was motivated by the rapid increase 
in connectivity within and outside government 
and the growth in federal support for large-scale 
networks. The report focused on safeguarding in¬ 
formation in networks, not on the security or sur¬ 
vivability of the networks themselves, nor on the 
reliability of network services to ensure informa¬ 
tion access. 

The report identified policy issues and options in 
three areas: 1) cryptography policy, including fed¬ 
eral information processing standards and export 
controls; 2) guidance on safeguarding unclassi¬ 
fied information in federal agencies; and 3) legal 
issues and information security, including elec¬ 
tronic commerce, privacy, and intellectual proper¬ 
ty. The report concluded that Congress has a vital 
role in formulating national cryptography policy 
and in determining how we safeguard information 
and protect personal privacy in an increasingly 
networked society (see outline of policy issues 
and options in the last section of this chapter and 
the expanded discussion in appendix D). 

I Importance of Cryptography 

Cryptography (see box 2-1) and related federal 
policies (e.g., regarding export controls and stan¬ 


dards development) were a major focus of the re¬ 
port. 8 That focus was due in part from the 
widespread attention being given the so-called 
Clipper chip and the Clinton Administration’s es¬ 
crowed-encryption initiative. Escrowed encryp¬ 
tion, or key-escrow encryption, refers to a 
cryptosystem in which the functional equivalent 
of a “spare key” must be deposited with a third 
party, in order to ensure easy access to decryption 
keys pursuant to lawful electronic surveillance. 
The Clinton Administration’s escrowed-encryp¬ 
tion initiative, first announced in 1993, required 
the “spare keys” to be held within the executive 
branch. The Escrowed Encryption Standard 
(EES), promulgated as a federal information proc¬ 
essing standard (FIPS) in 1994, is approved for 
use in encrypting unclassified voice, fax, or data 
communicated in a telephone system. 9 

However, a focus on cryptography was inevita¬ 
ble, because in its modern setting, cryptography 
has become a fundamental technology with broad 
applications. Modern, computer-based cryptogra¬ 
phy and cryptanalysis began in the World War II 
era. 10 Much of this development has been 
shrouded in secrecy; in the United States, govern¬ 
mental cryptographic research has historically 
been the purview of the “national security” (i.e., 
defense and intelligence) communities. 11 

Now, however, cryptography is a technology 
whose time has come—in the marketplace and in 
society. Cryptography is not arcane anymore. De¬ 
spite two decades of growth in nongovernmental 
research and development, in the United States, 


6 Ibid. 

7 Ibid., pp. 5-6 and appendix A (congressional letters of request). 

8 Ibid., pp. 8-18 and chapter 4. 

9 The EES is implemented in hardware containing the Clipper chip. The EES (FIPS-185) specifies use of a classified, symmetric encryption 
algorithm, called "Skipjack.” which was developed by the National Security Agency. The “Capstone chip” implements the Skipjack algorithm 
for use in computer network applications. The Defense Department’s “FORTEZZA card” (a PCMCIA card formerly called “TESSERA") con¬ 
tains the Capstone chip. 

10 See, e.g., David Kahn, The Codebreakers (New York, NY: MacMillan. 1967). 

11 Although there has always been some level of nongovernmental cryptography research in the United States, from the end of WWII 
through the mid-1970s the federal government was almost the sole U.S. source of technology and know-how for modern cryptographic safe¬ 
guards. The government's former near-monopoly in development and use of cryptography has been eroding, however. 
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BOX 2-1: Cryptograph 


During the long history of paper-based “information systems” for commerce and communication, a num¬ 
ber of safeguards were developed to ensure the confidentiality, integrity, and authenticity of documents and 
messages. These traditional safeguards included secret codebooks and passwords, physical “seals” to au¬ 
thenticate signatures, and auditable bookkeeping procedures. Mathematical analogues of these safeguards 
are implemented in the electronic environment. The most powerful of these are based on cryptography. 

The recorded history of cryptography is more than 4,000 years old, Manual encryption methods using 
codebooks, letter and number substitutions, and transpositions have been used for hundreds of years—for 
example, the Library of Congress has letters from Thomas Jefferson to James Madison containing en¬ 
crypted passages. Modern, computer-based cryptography and cryptanalysts began in the World War II 
era, with the successful Allied computational efforts to break the ciphers generated by the German Enigma 
machines, and with the British Colossus computing machines used to analyze a crucial cipher used in the 
most sensitive German teletype messages. 

In the post-WWII era, the premiere locus of U.S. cryptographic research and (especially) research in 
cryptanalysts has been the Defense Department’s National Security Agency (NSA). NSA’s preeminent posi¬ 
tion results from its extensive role in U.S. signals intelligence and in securing classified communications, 
and the resulting need to understand cryptography as a tool to protect information and as a tool used by 
adversaries. 

In its modern setting, cryptography is a field of applied mathematics/computer science. Cryptographic 
algorithms—specific techniques for transforming the original input into a form that is unintelligible without 
special knowledge of some secret (closely held) information—are used to encrypt and decrypt messages, 
data, or other text. The encrypted text is often referred to as ciphertext; the original or decrypted text is 
often referred to as plaintext or cleartext. In modern cryptography, the secret information is the crypto¬ 
graphic key that “unlocks” the ciphertext and reveals the plaintext. 

The encryption algorithms and key or keys are implemented in a cryptosystem. The key used to de¬ 
crypt can be the same as the one used to encrypt the original plaintext, or the encryption and decryption 
keys can be different (but mathematically related), One key is used for both encryption and decryption in 
symmetric , or “conventional” cryptosystems; in asymmetric , or “public-key” cryptosystems, the encryption 


the federal government still does have the most 
expertise in cryptography. Nevertheless, cryptog¬ 
raphy is not just a “government” technology any¬ 
more, either. Because it is a technology of broad 
application, the effects of federal policies about 
cryptography are not limited to technological de¬ 
velopments in the field, or even to the health and 
vitality of companies that produce or use products 
incorporating cryptography. Instead, these poli¬ 
cies will increasingly affect the everyday lives of 
most Americans. 

Encryption (see box 2-2) transforms a message 
or data files (called “plaintext”) into a form (called 
“ciphertext”) that is unintelligible without special 
knowledge of some secret information (called the 
“decryption key”). Figures 2-1 and 2-2 illustrate 


two common forms of encryption: 1) secret-key, 
or symmetric, encryption and 2) public-key, or 
asymmetric, encryption. Note that key manage¬ 
ment—the generation of encryption and decryp¬ 
tion keys, as well as their storage, distribution, 
cataloging, and eventual destruction-is crucial 
for the overall security of any encryption system. 
In some cases (e.g., for archival records), when 
files or databases are encrypted, the keys have to 
remain cataloged and stored for very long periods 
of time. 

Encryption can be used as a tool to protect the 
confidentiality of information in messages or 
files-hence, to help protect personal privacy. 
Other applications of cryptography can be used to 
protect the integrity of information (that it has not 
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BOX 2-1 (cont’d.): Cryptography 


and decryption keys are different and one of them can be made public. With the advent of “public-key” 
techniques, cryptography also came into use for digital signatures that are of widespread interest as a 
means for electronically authenticating and signing commercial transactions like purchase orders, tax re¬ 
turns, and funds transfers, as well as ensuring that unauthorized changes or errors are detected. 

Cryptanalysis is the study and development of various “codebreaking” methods to deduce the contents of 
the original plaintext message. The strength of an encryption algorithm is a function of the number of steps, 
storage, and time required to break the cipher and read any encrypted message, without prior knowledge of 
the key. Mathematical advances, advances in cryptanalysts, and advances in computing, all can reduce the 
security afforded by a cryptosystem that was previously considered “unbreakable” in practice. 

The strength of a modern encryption scheme is determined by the algorithm itself and the length of the 
key, For a given algorithm, strength increases with key size. However , key size alone is a not a valid means 
of comparing the strength of two different encryption systems. Differences in the properties of the algo¬ 
rithms may mean that a system using a shorter key is stronger overall than one using a longer key. 

Key management is fundamental and crucial to the security afforded by any cryptography-based safe¬ 
guard. Key management includes generation of the encryption key or keys, as well as their storage, dis¬ 
tribution, cataloging, and eventual destruction. If secret keys are not closely held, the result is the same as 
if a physical key is left “lying around” to be stolen or duplicated without the owner's knowledge. Similarly, 
poorly chosen keys may offer no more security than a lock that can be opened with a hairpin. Changing 
keys frequently can limit the amount of information or the number of transactions compromised due to un¬ 
authorized access to a given key. Thus, a well-thought-out and secure key-management infrastructure is 
necessary for effective use of encryption-based safeguards in network environments. Such a support infra¬ 
structure might include means for issuing keys and/or means for registering users’ public keys and linking 
owner-registration certificates to keys so that the authenticity of digital signatures can be verified. This 
might be done by a certificate authority as part of a public-key infrastructure. 

SOURCE: Office of Technology Assessment, 1995; drawing from OTA, Information Security and Privacy in Network Environments 
(OTA-TCT-606, September 1994), pp. 112-113 and sources cited therein. 


been subject to unauthorized or unexpected 
changes) and to authenticate its origin (that it 
comes from the stated source or origin and is not a 
forgery). 

Thus, cryptography is a technology that will 
help speed the way to electronic commerce. With 
the advent of what are called public-key tech¬ 
niques, cryptography came into use for digital sig¬ 
natures (see figure 2-3) that are of widespread 
interest as a means for electronically authenticat¬ 


ing and signing commercial transactions like pur¬ 
chase orders, tax returns, and funds transfers, as 
well as for ensuring that unauthorized changes or 
errors are detected (see discussion of message au¬ 
thentication and digital signatures in box 2-2). 12 
These functions are critical for electronic com¬ 
merce. Cryptographic techniques like digital 
signatures can also be used to help manage copy¬ 
righted material in electronic form. 13 


i: OTA, op. cit., footnote 4, pp. 69-77. See also Lisa Morgan, “Cashing In: The Rush Is on To Make Net Commerce Happen,” Internet World, 
February 1995, pp. 48-51; and Richard W. Wiggirts, “Business Browser: A Tool To Make Web Commerce Secure,” Internet World, February 
1995, pp. 52-55. 

13 OTA, ibid., pp. 96- 110. For example, digital signatures can be used to create compact “copyright tokens” for use in registries; encryption 
could be used to create personalized “copyright envelopes” for direct electronic delivery of material to customers. See also Working Group on 
Intellectual Property Rights, IITF, “Intellectual Property and the National Information Infrastructure (Green Paper),” July 1994, pp. 139-140. 


i 
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BOX 2-2: Encryption, Authentication, and Digital Signatures 


Different cryptographic methods are used to authenticate users, protect confidentiality, and assure in¬ 
tegrity of messages and files. Most systems use a combination of techniques to fulfill these functions. 

Encryption 

Cryptographic algorithms are either symmetric or asymmetric, depending on whether or not the same 
cryptographic key is used for encryption and decryption. The key is a sequence of symbols that deter¬ 
mines the transformation from unencrypted plaintext to encrypted ciphertext, and vice versa. 

“Symmetric” cryptosystems—also called secret-key or single-key systems—use the same key to en¬ 
crypt and decrypt messages. Both the sending and receiving parties must know the secret key that they 
will use to communicate (see figure 2-1 in the main text). Secret-key algorithms can encrypt and decrypt 
relatively quickly, but systems that use only secret keys can be difficult to manage because they require a 
courier, registered mail, or other secure means for distributing keys. The federal Data Encryption Standard 
(DES) and the new Escrowed Encryption Standard (EES) each use a different secret-key algorithm. 

“Asymmetric” cryptosystems—also called public-key systems—use one key to encrypt and a different, 
but mathematically related, public key to decrypt messages (see figure 2-2). For example, if an associate 
sends Carol a message encrypted with Carol’s public key, in principle only Carol can decrypt it, because 
she is the only one with the correct private key This provides confidentiality and can be used to distribute 
secret keys, which can then be used to encrypt messages using a faster, symmetric cryptosystem (see 
figure 2-3). 

The security of public-key systems rests on the authenticity of the public key (that it is a valid key for 
the stated individual or organization, not “recalled” by the owner or presented by an impostor) and the 
secrecy of the private key, much as the security of symmetric ciphers rests on the secrecy of the single 
key. Although the public key can be freely distributed, or posted in the equivalent of a telephone directory, 
its authenticity must be assured (e.g., by a certificate authority as part of a public-key infrastructure). 

Commonly used public-key systems encrypt relatively slowly, but are useful for digital signatures and 
for exchanging the session keys that are used for encryption with a faster, symmetric cryptosystem. The 
Rivest-Shamir-Adleman (RSA) algorithm is a well-known, commercial public-key algorithm. 

Authentication 

The oldest and simplest forms of message authentication use “secret” authentication parameters known 
only to the sender and intended recipient to generate “message authentication codes. ” So long as the se¬ 
cret authentication parameter is kept secret from all other parties, these techniques protect the sender and 
the receiver from alteration or forgery of a message by all such third parties. Because the same secret 
information is used by the sender to generate the message authentication code and by the receiver to 
validate it, these techniques cannot settle “disputes” between the sender and receiver as to what mes¬ 
sage, if any, was sent. For example, message authentication codes could not settle a dispute between a 
stockbroker and client in which the broker claims the client issued an order to purchase stock and the 
client claims he never did so. 

For authentication, if a hypothetical user (Carol) uses her private key to sign messages, her associates 
can verify her signature using her public key. This method authenticates the sender, and can be used with 
hashing functions (see below) for a digital signature that can also check the integrity of the message. 

Digital Signatures 

Digital signatures provide a higher degree of authentication by allowing resolution of disputes. Although 
it is possible to generate digital signatures from a symmetric cipher like the DES, most interest centers on 
signature systems based on public-key cryptosystems. 
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BOX 2-2 (cont’d.): Encryption, Authentication, and Digital Signatures 


In principle, to sign a message using a public-key encryption system, a user could transform it with his 
private key, and send both the original message and the transformed version to the intended receiver. The 
receiver would validate the message by acting on the transformed message with the sender’s public key 
(obtained from the “electronic phone book”) and seeing that the result matched the original message. Be¬ 
cause the signing operation depends on the sender’s private key (known only to him or her), it is impossi¬ 
ble for anyone else to sign messages in the sender's name. But everyone can validate such signed mes¬ 
sages, since the validation depends only on the sender's “public” key. 

In practice, digital signatures sign shorter “message digests” rather than the whole messages. In most 
public-key signature techniques, a one-way hash function is used to produce a condensed version of the 
message, which is then “signed. ” For example, Carol processes her message with a ‘(hashing algorithm” 
that produces a shorter message digest—the equivalent of a very long checksum. Because the hashing 
method is a “one-way” function, the message digest cannot be reversed to obtain the message. Bob also 
processes the received text with the hashing algorithm and compares the resulting message digest with 
the one Carol signed and sent along with the message. If the message was altered in any way during 
transit, the digests will be different, revealing the alteration (see figure 2-4). 

Signature Alternatives 

With the commercial RSA system, the signature is created by encrypting the message digest, using the 
sender’s private key. Because in the RSA system each key is the inverse of the other, the recipient can use 
the sender’s public key to decrypt the signature, thereby recovering the original message digest. The re¬ 
cipient compares this with the one he or she has calculated using the same hashing function—if they are 
identical, then the message has been received exactly as sent and, furthermore, the message did come 
from the supposed sender (otherwise his or her public key would not have yielded the correct message 
digest). 

The federal Digital Signature Standard (DSS) defines a somewhat different kind of public-key crypto¬ 
graphic standard for generating and verifying digital signatures. The DSS is to be used in conjunction with 
a federal hashing standard that is used to create a message digest, as described above. The message 
digest is then used, in conjunction with the sender’s private key and the algorithm specified in the DSS, to 
produce a message-specific signature. Verifying the DSS signature involves a mathematical operation on 
the signature and message digest, using the sender's public key and the hash standard. 

The DSS differs from the RSA digital signature method in that the DSS signature operation is not revers¬ 
ible, and hence can only be used for generating digital signatures. DSS signature verification is different 
than decryption. In contrast, the RSA system can encrypt, as well as do signatures. Therefore, the RSA 
system can also be used to securely exchange cryptographic keys that are to be used for confidentiality 
(e.g., “secret” keys for use with a symmetric encryption algorithm like the DES). This lack of encryption 
capability for secure key exchange was one reason why the government selected the DSS technique for 
the standard. 

SOURCE: Office of Technology Assessment, 1995; drawing from OTA, Information Security and Privacy in Network Environments 
(OTA-TCT-606, September 1994), pp. 39 and 124-125 and sources cited therein See also U.S. Department of Commerce, National 
Institute of Standards and Technology, “Data Encryption Standard (DES), ” FIPS Publication 46-2, Dec 30, 1993; “Digital Signature 
Standard (DSS)," FIPS Publication 186, May 19, 1994; and “Escrowed Encryption Standard (EES), ” FIPS Publication 185, February 
1994. 
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FIGURE 2-1: Secret-Key (Symmetric) Encryption 
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Carol decrypts 
Ted’s messages 
with the same 
secret key 


Ted sends 
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to Carol using 
their secret key 


NOTE: Security depends on the secrecy of the shared key. 
SOURCE: Office of Technology Assessment, 1994. 


The nongovernmental markets for cryptogra¬ 
phy-based safeguards have grown over the past 
two decades, but are still developing. Good com¬ 
mercial encryption technology is available in the 
United States and abroad. Research in cryptogra¬ 
phy is international. Absent government regula¬ 
tions, markets for cryptography would also be 
international. However, export controls create 


“domestic” and “export” markets for strong en¬ 
cryption products (see section on export controls 
below and also appendix C. 14 User-friendly cryp¬ 
tographic safeguards that are integrated into prod¬ 
ucts (as opposed to those that the user has to 
acquire separately and add on) are still hard to 
come by—in part, because of export controls and 
other federal policies that seek to control cryptog¬ 
raphy." 

I Government Efforts To 
Control Cryptography 
In its activities as a developer, user, and regulator 
of safeguard technologies, the federal government 
faces a fundamental tension between two policy 
objectives, each of which is important: 1) fos¬ 
tering the development and widespread use of 
cost-effective information safeguards, and 2) con¬ 
trolling the proliferation of safeguard technolo¬ 
gies that can impair U.S. signals-intelligence and 
law enforcement capabilities. Cryptography is at 
the heart of this tension. Export controls and the 
federal standards process (i.e., the development 
and promulgation of federal information process¬ 
ing standards, or FIPS) are two mechanisms the 
government can use to control cryptography. 16 

Policy debate over cryptography used to be as 
arcane as the technology itself. Even five or 10 
years ago, few people saw a link between govern¬ 
ment decisions about cryptography and their daily 
lives. However, as the information and commu¬ 
nications technologies used in daily life have 
changed, concern over the implications of policies 
traditionally dominated by national security ob¬ 
jectives has grown dramatically. 

Previously, control of the availability and use of 
cryptography was presented as a national security 
issue focused outward, with the intention of main¬ 
taining a U.S. technological lead over other coun¬ 
tries and preventing encryption devices from 


“OTA, ibid., pp. 11-13, 150-160. 

“Ibid., pp. 115-123, 128-132, 154-160. 

16 For more detail, see ibid., chapters 1 and 4, and appendix C. Other means of control have historically included include national security 
classification and patent-secrecy orders (see ibid., p. 128 and footnote 33). 
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FIGURE 2-2: Public-Key (Asymmetric) Encryption 
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NOTE: Security depends on the secrecy of the private keys and the authenticity of the public keys. 
SOURCE: Office of Technology Assessment, 1994 
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FIGURE 2-3: Example of a Hashing and Digital Signature Scheme 
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NOTE: Different methods for generating and verifying signatures (as in the federal Digital Signature Standard) are possible. Measures to protect the 
signature and text may also be used. 

SOURCE: Office of Technology Assessment, 1994 


falling into the “wrong hands” overseas. More 
widespread foreign use—including use of strong 
encryption by terrorists and developing coun¬ 
tries—makes U.S. signals intelligence more dif¬ 
ficult. 

Now, with an increasing policy focus on domes¬ 
tic crime and terrorism, the availability and use of 
cryptography has also come into prominence as a 
domestic-security, law enforcement issue. Within 
the United States, strong encryption is increasing¬ 


ly portrayed as a threat to domestic security (pub¬ 
lic safety) and a barrier to law enforcement if it is 
readily available for use by terrorists or criminals. 
There is also growing recognition of potentials for 
misuse, such as by disgruntled employees as a 
means to sabotage an employer’s databases. Thus, 
export controls, intended to restrict the intern¬ 
ational availability of U.S. cryptography technolo¬ 
gy and products, are now being joined with 
domestic cryptography initiatives, like key-es- 
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crow encryption, that are intended to preserve 
U.S. law enforcement and signals-intelligence ca¬ 
pabilities (see box 2-3). 

Standards-development and export-control is¬ 
sues underlie a long history of concern over lead¬ 
ership and responsibility (i.e., “who should be in 
charge?” and “who is in charge?”) for the secu¬ 
rity of unclassified information government¬ 
wide. 17 Most recently, these concerns have been 
revitalized by proposals (presented by the Clinton 
Administration’s Security Policy Board staff) to 
centralize information-security authorities gov¬ 
ernment-wide under joint control of the Office of 
Management and Budget (OMB) and Department 
of Defense (DOD) (see discussion in chapter 4). 18 

Other manifestations of these concerns can be 
found in the history of the Computer Security Act 
of 1987 (Public Law 100-235—see the next sec¬ 
tion and appendix B) and in more recent develop¬ 
ments, such as public reactions to the Clinton 
Administration's key-escrow encryption initia¬ 
tive and the controversial issuances of the Es¬ 
crowed Encryption Standard 19 and Digital 
Signature Standard (DSS) 20 as federal informa¬ 
tion processing standards. Another important 
manifestation of these concerns is the controversy 
over the present U.S. export control regime, 
which includes commercial products with capa¬ 
bilities for strong encryption, including mass- 
market software, on the Munitions List, under 
State Department controls (see below and appen¬ 
dix C). 


The Escrowed Encryption Standard has been 
promulgated by the Clinton Administration as a 
voluntary federal encryption standard (i.e., a vol¬ 
untary, rather than mandatory, FIPS). The EES an¬ 
nouncement noted that the standard does not 
mandate the use of escrowed-encryption devices 
by government agencies or the private sector; the 
standard provides a mechanism for agencies to use 
key-escrow encryption without having to waive 
the requirements of another, extant federal en¬ 
cryption standard for unclassified information, 
the Data Encryption Standard (DES). 21 

The EES is intended for use in encrypting 
unclassified voice, facsimile, and computer in¬ 
formation communicated over a telephone sys¬ 
tem . The encryption algorithm (called Skipjack) 
specified in the EES can also be implemented for 
data communications in computer networks. At 
this writing, there is no FIPS specifying use of 
Skipjack as a standard algorithm for data commu¬ 
nications or file encryption. 

However, DOD is using Skipjack for encryption 
in computer networks (e.g., in the “FORTEZZA” 
PCMCIA card). As of April 1995, according to 
the National Security Agency (NSA), approxi¬ 
mately 3,000 FORTEZZA cards have been pro¬ 
duced and another 33,000 are on contract; some 
100 to 200 arc being tested and used in applica¬ 
tions development by various DOD organiza¬ 
tions, mostly in support of the Defense Message 
System. 22 According to the NSA, plans call for 


17 Ibid., pp. 8-20 and chapter 4. 

18 U.S. Security Policy Board Staff. “Creating a New Order in U.S. Security Policy," Nov. 21, 1994, pp. II-III, 14-18. 

19 See box 2-3 and OTA, op. cit., footnote 4, ch. 4. 

20 See box 2-2 and OTA, ibid., appendix C. 

21 See Federal Register, vol. 59, Feb. 9. 1994, pp. 5997-6005 ("Approval of Federal Information Processing Standards Publication 185, 
Escrowed Encryption Standard (EES)”), especially p. 5998. Note, however, that the DES is approved for encryption of unclassified data com¬ 
munications and files, while the EES is only a standard for telephone communications at this time. 

22 Bob Drake, Legislative Affairs Office, NSA, personal communication, Apr. 7. 1995. 
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BOX 2-3: The Escrowed Encryption Standard 


The federal Escrowed Encryption Standard (EES) was approved by the Commerce Department as a 
federal information processing standard (FIPS) in February 1994.'According to the standard (described in 
FIPS PUB 185), the EES is intended for voluntary use by all federal departments and agencies and their 
contractors to protect unclassified information. Implementations of the EES are subject to State Department 
export controls. In 1994, however, the Clinton Administration indicated that encryption products based on 
the EES would be exportable to most end users and that EES products will qualify for special licensing 
arrangements. 1 2 

The National Security Council, Justice Department, Commerce Department, and other federal agencies 
were involved in the decision to propose the EES, according to a White House press release and informa¬ 
tion packet dated April 16, 1993, the day the EES initiative was announced. The EES algorithm is said to be 
stronger than the Data Encryption Standard (DES) algorithm, but able to meet the legitimate needs of law 
enforcement agencies to protect against terrorists, drug dealers, and organized crime. 3 

EES Functions 

The EES is intended to encrypt voice, fax, and computer data communicated in a telephone system. It 
may, on a voluntary basis, be used to replace DES encryption devices now in use by federal agencies and 
contractors. Other use by the private sector is voluntary. The EES specifies a symmetric encryption algo¬ 
rithm, called “Skip jack.” The Skipjack algorithm is a classified algorithm, developed by the National Securi¬ 
ty Agency (NSA) in the 1980s. 4 An early implementation was called Clipper, hence the colloquial use of 
Clipper or Clipper Chip to describe the EES technology. 5 

The EES also specifies a method to create a Law Enforcement Access Field (LEAF), in order to provide 
for easy decryption when the equivalent of a wiretap has been authorized.“The Skipjack algorithm and 
LEAF creation method are implemented only in electronic devices (i.e., very-large-scale integration chips). 
The chips are “highly resistant” to reverse engineering and will be embedded in tamper-resistant crypto¬ 
graphic modules that approved manufacturers can incorporate in telecommunications or computer equip¬ 
ment. The chips are manufactured by VLSI Logic and are programmed with the algorithms and keys by 
Mykotronx. The programming is done under the supervision of the two “escrow agents” (see below). 


1 See Federal Register, vol. 59. Feb. 9, 1994, pp. 5997-6005. 

2 Martha Flarris, Deputy Assistant Secretary of State for Political-Military Affairs, “Statement on Encryption-Export Control Re¬ 
form, ” Feb. 4, 1994 [OTA note The anticipated reforms had not all materialized as of this writing.] 

’Because the EES algorithm is classified, the overall strength of the EES cannot be examined except under security clearance 
(see below). Thus, unclassified, public analyses of its strengths and weaknesses are not possible. The only public statements made 
by the Clinton Administration concerning the strength of the EES relative to the DES refer to the secret-key size: 80 bits for the EES 
versus 56 bits for the DES 

‘The NSA specifications for Skipjack and the LEAF creation method are classified at the Secret level. (OTA project staff did not 
access these, or any other classified information.) 

The Clipper Chip implementation of Skipjack is for use in secure telephone communications. An enhanced escrowed-encryption 
chip with additional functions, called Capstone, is used in data communications. Capstone is in the FORTEZZA PCMCIA card being 
used in the Defense Message System 

‘See Jo Ann Flarris, Assistant Attorney General, Criminal Division, Department of Justice, testimony before the Subcommittee on 
Technology and the Law, Committee on the Judiciary, U.S. Senate, May 3, 1994; and James K. Kallstrom, Special Agent in Charge, 
Special Operations Division, Federal Bureau of Investigation, testimony before the Subcommittee on Technology, Environment, and 
Aviation, Committee on Science, Space, and Technology, U.S. Flouse of Representatives, May 3, 1994 For a discussion of law en¬ 
forcement concerns and the rationale for government key escrowing, see also Dorothy E. Denning, "The Clipper Encryption System, ” 
American Scientist, vol. 81, July-August 1993, pp. 319-322; and “Encryption and Law Enforcement, ” Feb. 21, 1994, available from 
denning@cs.georgetown.edu 
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BOX 2-3 (cont’d.): The Escrowed Encryption Standard 


After electronic surveillance has been authorized, the EES facilitates law enforcement access to en¬ 
crypted communications. This is accomplished through what is called a “key escrowing” scheme. Each 
EES chip has a chip-specific key that is split into two parts after being programmed into the chips. These 
parts can be recombined to gain access to encrypted communications. One part is held by each of two 
designated government keyholders, or “escrow agents.” Attorney General Reno designated the National 
Institute of Standards and Technology (NIST) and the Treasury Department’s Automated Systems Division 
as the original escrow agents. The only public estimate (by NIST, in early 1994) of the costs of establishing 
the escrow system was about $14 million, with estimated annual operating costs of$16 million. 

When surveillance has been authorized and the intercepted communications are found to be encrypted 
using the EES, law enforcement agencies can obtain the two parts of the escrowed key from the escrow 
agents. These parts can then be used to obtain the individual keys used to encrypt (and, thus, to decrypt) 
the telecommunications sessions of interest.The LEAF is transmitted along with the encrypted message; it 
contains a device identifier that indicates which escrowed keys are needed. 

EES History 

The proposed FIPS was announced in the Federal Register on July 30, 1993, and was also sent to fed¬ 
eral agencies for review. The EES was promulgated after a comment period that generated almost univer¬ 
sally negative comments. According to NIST, comments were received from 22 government organizations 
in the United States, 22 industry organizations, and 276 individuals. Concerns and questions reported by 
NIST include the algorithm itself and lack of public inspection and testing, the role of NSA in promulgating 
the standard, use of key escrowing, possible infringement of individual rights, effects of the standard on 
U.S. firms’ competitiveness in foreign markets, cost of establishing the escrowing system, and cost-effec¬ 
tiveness of the new standard. 8 

During the review period, the Skipjack algorithm was evaluated by outside experts, pursuant to Presi¬ 
dent Clinton’s direction that “respected experts from outside the government will be offered access to the 
confidential details of the algorithm to assess its capabilities and publicly report their findings. ” Five re¬ 
viewers accepted NIST’s invitation to participate in a classified review of Skipjack and publicly report their 
findings: Ernest Brickell (Sandia National Laboratories), Dorothy Denning (Georgetown University), Ste¬ 
phen Kent (Bolt Beranek and Newman, Inc.), David Maher (AT&T), and Walter Tuchman (Amperif Corp.). 
Their interim report on the algorithm itself found that: 1) there is no significant risk that Skipjack will be 
broken by exhaustive search in the next 30 to 40 years; 2) there is no significant risk that Skipjack can be 
broken through a shortcut method of attack; and 3) while the internal structure of Skipjack must be classi¬ 
fied in order to protect law enforcement and national security objectives, the strength of Skipjack against a 
cryptanalytic attack does not depend on the secrecy of the algorithm. 9 


'Requirements for federal and state law enforcement agents to certify that electronic surveillance has been authorized, and for 
what period of time, as well as requirements for authorized use of escrowed key components are explained in Department of Justice, 
"Authorization Procedures for Release of Encryption Key Components in Conjunction with Intercepts Pursuant to Title III, ” “Authoriza¬ 
tion Procedures for Release of Encryption Key Components in Conjunction with Intercepts Pursuant to State Statutes, ” and "Authoriza¬ 
tion Procedures for Release of Encryption Key Components in Conjunction with Intercepts Pursuant to FISA, ” Feb. 4, 1994. 

' Federal Register (Feb. 9, 1994), op. cit. footnote 1, pp. 5998-6002. 

9 E. Brickell (Sandia National Laboratories) et al., “SKIPJACK Review Interim Report-The SKIPJACK Algorithm, ” July 28, 1993. 
See also "Fact Sheet—NIST Cryptography Activities," Feb. 4, 1994 

(continued) 
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BOX 2-3 (cont’d.): The Escrowed Encryption Standard 


Based on its review of the public comments, NIST recommended that the Secretary of Commerce issue 
the EES as a federal information processing standard. ,0 NIST noted that almost all of the comments re¬ 
ceived during the review period were negative, but concluded that, “many of these comments reflected 
misunderstanding or skepticism that the EES would be a voluntary standard.” 11 The Clinton Administration 
also carried out a 10-month encryption policy review that presumably played a role in choosing to issue the 
EES as a FIPS, but the substance of that review has not been made public and was not available to OTA. 
Additionally, the Clinton Administration created an interagency working group on encryption and telecom¬ 
munications that includes representatives of agencies that participated in the policy review. The interagen¬ 
cy group was to “work with industry on technologies like the Key Escrow chip [i. e., EES], to evaluate pos¬ 
sible alternatives to the chip, and to review Administration policies regarding encryption as developments 
warrant. ”' 2 

In early 1995, an alternative, commercial key-escrow encryption system being developed by Trusted 
Information Systems, Inc. (TIS) was undergoing internal government review to determine whether such an 
approach could meet national security and law enforcement objectives. The TIS key-escrow system does 
software-based escrowing and encryption using the “triple-DES” version of the Data Encryption Stan¬ 
dard. ,3 The initial version of the system is designed for use in encrypting files or email, but the TIS ap¬ 
proach could also be used for real-time telecommunications. 

In January 1995, AT&T Corp. and VLSI Technology, Inc., announced plans to develop chips implement¬ 
ing the RSA algorithm and “triple DES” for encryption. The chips would be used in a personal computers, 
digital telephones, and video decoder boxes. 14 


“Ibid., and Federal Register ( Feb. 9, 1994), OP. Cit., footnote 1. 

!l Ibid. 

“White House press release and enclosures, Feb. 4, 1994, “Working Group on Encryption and Telecommunications." 
"Stephen T. Walker et al., "Commercial Key Escrow: Something for Everyone Nowand For the Future, ” TIS Report No. 541, 
Trusted Information Systems, Inc., Jan. 3, 1995. 

“Jared Sandberg and Don Clark, “AT&T, VLSI Technology To Develop Microchips That Offer Data Security,The Wall Street Jour¬ 
nal, Jan. 31, 1995. 

SOURCE: Off Ice of Technology Assessment, 1995: drawing from OTA, Information Security And Privacy in Networked Environments 
(OTA-TCT-606, September 1994), pp. 118-119 and sources cited therein and below. 


eliciting and aggregating bulk orders for FOR- 
TEZZA in order to support the award of a large- 
scale production contract in the fall, ideally for 
200,000 to 400,000 units in order to achieve the 
target unit price of $100. 23 

The algorithm specified in the EES has not been 
published. The secret encryption key length for 


Skipjack is 80 bits; a key-escrowing scheme is 
built into ensure “lawfully authorized” electronic 
surveillance. 24 The algorithm is classified and is 
intended to be implemented only in tamper-resis¬ 
tant, hardware modules. 25 This approach makes 
the confidentiality function of the Skipjack en- 


“Ibid. According to the NSA, unit prices for FORTEZZA cards in small quantities are on the order of $150, of which about $98 is for the 
Capstone chip. The Capstone chip implements the Skipjack algorithm, plus key-exchange and digital-signature (DSS) functions. 

24 Federal Register, ibid., p. 6003. 

25 Federal Register, ibid., pp. 5997-6005. 


< 
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cryption algorithm available in a controlled fash¬ 
ion, without disclosing the algorithm’s design 
principles or thereby increasing users’ abilities to 
employ cryptographic principles. One of the rea¬ 
sons stated for specifying a classified, rather than 
published, encryption algorithm in the EES is to 
prevent independent implementation of Skipjack 
without the law enforcement access features. 

The federal Data Encryption Standard was first 
approved in 1976 and was most recently reaf¬ 
firmed in 1993. The DES specifies an algorithm 
that can be used to protect unclassified informa¬ 
tion, as needed, while it is being communicated or 
stored. 26 The DES algorithm has been made pub¬ 
lic (i.e., it has been published). When the DES is 
used, users can generate their own encryption 
keys; the secret encryption key for DES is 56 bits 
long. The DES does not require the keys to be “es¬ 
crowed” or deposited with any third party. 

The 1993 reaffirmation of the DES—now in 
software, as well as hardware and firmware imple¬ 
mentations—may be the last time it is reaffirmed 
as a federal standard. FIPS Publication 46-2 
(“Data Encryption Standard”) noted that the algo¬ 
rithm will be reviewed within five years to assess 
its adequacy against potential new threats, includ¬ 
ing advances in computing and cryptanalysis: 

At its next review (1998) [the DES algorithm] 
will be over twenty years old. NIST [National Insti¬ 
tute of Standards and Technology] will consider al¬ 
ternatives which offer a higher level of security. 
One of these alternatives may be proposed as a re¬ 
placement standard at the 1998 review. 27 


Given that the Skipjack algorithm was selected as 
a standard (the EES) for telephony, it is possible 
that an implementation of Skipjack (or some other 
form of key-escrow encryption) will be selected as 
a FIPS to replace the DES for computer commu¬ 
nications and/or file encryption. 

An alternative successor to the DES that is fa¬ 
vored by nongovernmental users and experts is a 
variant of DES called triple-encryption DES. In 
“triple DES,” the algorithm is used sequentially 
with three different keys, to encrypt, decrypt, then 
re-encrypt. Triple encryption with the DES offers 
more security than having a 112-bit DES key. 
Therefore, nongovernmental experts consider that 
triple DES “appears inviolate against all adver¬ 
saries for the foreseeable future.” 28 There is, how¬ 
ever, no FIPS for triple-encryption DES. 

Unlike the EES algorithm, the algorithm in the 
federal Digital Signature Standard has been pub¬ 
lished. 29 The public-key algorithm specified in 
the DSS uses a private key in signature generation, 
and a corresponding public key for signature veri¬ 
fication (see box 2-2). However, the DSS tech¬ 
nique was chosen so that public-key encryption 
functions would not be available to users. 30 This 
is significant because public-key encryption is ex¬ 
tremely useful for key management and could, 
therefore, contribute to the spread and use of non- 
escrowed encryption. 31 At present, there is no 
FIPS for key exchange. 

While other means of exchanging electronic 
keys are possible, 32 none is so mature as public- 


26 NIST, “Data Encryption Standard (DES),” FIPS PUB 46-2 (Gaithersburg, MD: U.S. Department of Commerce, Dec. 30, 1993). 

27 Ibid., p. 6. 

28 Martin Heilman, Professor of Electrical Engineering, Stanford University, personal communication, May 24, 1994; also see box 4-3 of 
the 1994 report. 

29 See appendix C of OTA, op. cit., footnote 4, for a history of the DSS. 

30 According to F. Lynn McNulty, NIST Associate Director for Computer Security, the rationale for adopting the technique used in the DSS 
was that, “We wanted a technology that did signatures—and nothing else—very well.” (Response to a question from Chairman Rick Boucher in 
testimony before the Subcommittee on Science of the House Committee on Science, Space, and Technology, Mar. 22, 1994.) 

31 Public-key encryption can be used for confidentiality and, thereby, for secure key exchange. Thus, public-key encryption can facilitate 
the use of symmetric encryption methods like the DES or triple DES. See figure 2-3. 

32 See, e.g., Tom Leighton (Department of Mathematics, Massachusetts Institute of Technology), and Silvio Micali (MIT Laboratory for 
Computer Science), “Secret-Key Agreement Without Public-Key Cryptography (extended abstract),” obtained from S. Micali, 1993. 
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FIGURE 2-4: Secret-Key Distribution Using Public-Key Cryptography 


Carol Ted 




NOTE: Security depends on the secrecy of the session key and private keys, as well as the authenticity of the public keys. 
SOURCE: Office of Technology Assessment, 1994. 


key technology. In contrast to the technique cho¬ 
sen for the DSS, the technique used in the most 
widely used commercial digital signature system 
(based on the Rivest-Shamir-Adleman, or RSA, 
algorithm) can also encrypt. Therefore, the RSA 
techniques can be used for secure key exchange 
(i.e., exchange of “secret”keys, such as those used 
with the DES), as well as for signatures (see figure 


2-4). Another public-key technique, called the 
Diffie-Hellman method, can also be used to gener¬ 
ate encryption keys (see figure 2-5), but does not 
encrypt.’’ 

The 1994 OTA report concluded that both the 
EES and the DSS are federal standards that are 
part of a long-term control strategy intended to re- 


33 The public-key concept was first published by Whitfield Diffie and Martin Heilman in “New Directions in Cryptography, ’ 'IEEE Transac¬ 
tions on Information Theory, vol. IT-22, No. 6, November 1976, pp. 644-654. Diffie and Heilman described how such a system could be used for 
key distribution and to “sign” individual messages. 
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SOURCE: Office of Technology Assessment, 1994. 


tard the general availability of “unbreakable” or 
“hard to break” encryption within the United 
States, for reasons of national security and law en¬ 
forcement. 4 OTA viewed the EES and DSS as 
complements in this overall control strategy, in¬ 
tended to discourage future development and use 
of encryption without built-in law enforcement 
access, in favor of key-escrowed and related en¬ 
cryption technologies. If the EES and/or other 


key-escrow encryption standards (e.g., for use in 
computer networks) become widely used-or en¬ 
joy a large, guaranteed government market—this 
could ultimately reduce the variety of alternative 
cryptography products through market domi¬ 
nance that makes alternatives more scarce or more 
costly. 


‘See OTA. op.cit., footnote 4, ch. 4. 
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Federal Standards and the 
Computer Security Act of 1987 

The Computer Security Act of 1987 (Public Law 
100-235) is fundamental to development of feder¬ 
al standards for safeguarding unclassified in¬ 
formation, to balancing national security and 
other objectives in implementing security and pri¬ 
vacy policies within the federal government, and 
to other issues concerning government control of 
cryptography. Implementation of the Computer 
Security Act has been controversial, especially re¬ 
garding the respective roles of NIST and NSA in 
standards development and the chronic shortage 
of resources for NIST’s computer security pro¬ 
gram to fulfill its responsibilities under the act 
(see detailed discussion in chapter 4 of the 1994 
OTA report). 35 

The Computer Security Act of 1987 was a legis¬ 
lative response to overlapping responsibilities for 
computer security among several federal agen¬ 
cies, heightened awareness of computer security 
issues, and concern over how best to control in¬ 
formation in computerized or networked form. 
The act established a federal government comput¬ 
er-security program that would protect all un¬ 
classified, sensitive information in federal 
government computer systems and would devel¬ 
op standards and guidelines to facilitate such 
protection. 

Specifically, the Computer Security Act as¬ 
signed responsibility for developing government¬ 
wide, computer-system security standards (e.g., 
the FIPS) and guidelines and security-training 
programs to the National Bureau of Standards 
(NBS). NBS is now the National Institute of Stan¬ 
dards and Technology, or NIST. According to its 
responsibilities under the act, NIST recommends 
federal information processing standards and 


guidelines to the Secretary of Commerce for ap¬ 
proval (and promulgation, if approved). These 
FIPS do not apply to classified or “Warner 
Amendment” systems. 36 NIST can draw on the 
technical expertise of the National Security 
Agency in carrying out its responsibilities, but the 
NS As role according to Public Law 100-235 is an 
advisory, rather than leadership, one. 

Section 21 of the Computer Security Act estab¬ 
lished a Computer System Security and Privacy 
Advisory Board. The board, appointed by the Sec¬ 
retary of Commerce, is charged with identifying 
emerging safeguard issues relative to computer 
systems security and privacy, advising the NBS 
(NIST) and Secretary of Commerce on security 
and privacy issues pertaining to federal computer 
systems, and reporting its findings to the Secre¬ 
tary of Commerce, the Director of OMB, the Di¬ 
rector of NS A, and Congress. Additionally, the act 
required federal agencies to identify computer 
systems containing sensitive information, to de¬ 
velop security plans for identified systems, and to 
provide periodic training in computer security for 
all federal employees and contractors who man¬ 
age, use, or operate federal computer systems. Ap¬ 
pendix B, drawn from the 1994 OTA report, 
provides more background on the puipose and im¬ 
plementation of the Computer Security Act and on 
the FIPS. 

Federal Standards and the Marketplace 

As the 1994 OTA report noted, not all government 
attempts at influencing the marketplace through 
the FIPS and procurement polices are successful. 
For example, the government made an early com¬ 
mitment to the Open Systems Interconnection 
(OSI) protocols for networking, but it is the ubiq¬ 
uitous Transmission Control Protocol/Internet 


'' Ibid., chapter 4 and appendix B. NIST's FY 1995 computer-security budget was on the order of $6.5 million, with $4.5 million of this 
coming from appropriated funds for “core” activities and the remainder from “reimbursable” funds from other agencies, mainly the Defense 
Department. 

36 Tha Warner Amendment (Public Law 97-86) excluded certain types of military and intelligence “automatic data processing equipment” 
procurements from the requirements of section 111 of the Federal Property and Administrative Services Act of 1949 (40 U.S.C. 795). Public 
Law 100-235 pertains to federal computer systems that come under section 111 of the Federal Property and Administrative Services Act of 
1949. 
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Protocol (TCP/IP) that has enjoyed wide use 
throughout the world in the Internet and other net¬ 
works. However, the FIPS usually influence the 
technologies used by federal agencies and provide 
a basis for interoperability, thus creating a large 
and stable, “target market"' for safeguard vendors. 
If the attributes of the standard technology are also 
applicable to the private sector and the standard 
has wide appeal, an even hu ger but still relatively 
stable market should result. The technological sta¬ 
bility means that firms compete less in terms of 
the attributes of the fundamental technology and 
more in terms of cost, ease of use, and so forth. 
Therefore, firms need to invest less in research and 
development (especially risky for a complex 
technology like cryptography) and in convincing 
potential customers of product quality. This can 
result in higher profits for producers, even in the 
long run, and in increased availability and use of 
safeguards based on the standard. 

In the 1970s, promulgation of the DES as a 
stable and certified technology—at a time when 
the commercial market for cryptography-based 
safeguards for unclassified information was 
emerging—stimulated supply and demand. Al¬ 
though the choice of the algorithm was originally 
controversial due to concerns over NS A’s involve¬ 
ment, the DES gained wide acceptance and has 
been the basis for several industry standards, in 
large paid because it was a published standard that 
could be freely evaluated and implemented. Al¬ 
though DES products are subject to U.S. export 
controls, DES technology is also widely available 
around the world and the algorithm has been 
adopted in several international standards. The 
process by which the DES was developed and 
evaluated also stimulated private sector interest in 
cryptographic research, ultimately increasing the 
variety of commercial safeguard technologies. 

The 1994 OTA report regarded the introduction 
of an incompatible new federal standard—for ex¬ 
ample, the Escrowed Encryption Standard—as 


destabilizing. At present, the EES and related 
technologies have gained little favor in the private 
sector—features such as the government key-es¬ 
crow agencies, classified algorithm, and hard- 
ware-only implementation all contribute to its 
lack of appeal. B ut, if the EES and related technol¬ 
ogies (e.g., for data communications) ultimately 
do manage to gain wide appeal in the marketplace, 
they might be able to “crowd out” safeguards that 
are based upon other cryptographic techniques 
and/or do not support key escrowing. 37 

The 1994 OTA report noted that this type of mar¬ 
ket distortion, intended to stem the supply of alter¬ 
native products, may be a long-term objective of 
the key-escrow encryption initiative. In the long 
term, a loss of technological variety is significant 
to private sector cryptography, because more di¬ 
verse research and development efforts tend to in¬ 
crease the overall pace of technological advance. 
In the near term, technological uncertainty may 
delay widespread investments in any new safe¬ 
guard, as users wait to see which technology pre¬ 
vails. The costs of additional uncertainties and 
delays due to control interventions are ultimately 
borne by the private sector and the public. 

Other government policies can also raise costs, 
delay adoption, or reduce variety. For example, 
export controls have the effect of segmenting do¬ 
mestic and export encryption markets. This 
creates additional disincentives to invest in the de¬ 
velopment—or use—of robust, but nonexport¬ 
able, products with integrated strong encryption 
(see discussion below). 

Export Controls 

Another locus of concern is export controls on 
cryptography (see appendix C). 38 The United 
States has two regulatory regimes for exports, de¬ 
pending on whether the item to be exported is mil¬ 
itary in nature, or is “dual-use,” having both 
civilian and military uses. These regimes are ad- 


77 Ibid., pp. 128-132. A large, stable, lucrative federal market could divert vendors from producing alternative, riskier products; product 
availability could draw private sector customers. 

38 For more detail, see ibid., chapters 1 and 4. 
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ministered by the State Department and the Com¬ 
merce Department, respectively. Both regimes 
provide export controls on selected goods or 
technologies for reasons of national security or 
foreign policy. Licenses are required to export 
products, services, or scientific and technical data 
originating in the United States, or to re-export 
these from another country. Licensing require¬ 
ments vary according to the nature of the item to 
be exported, the end use, the end user, and, in some 
cases, the intended destination. For many items 
under Commerce jurisdiction, no specific approv¬ 
al is required and a “general license” applies (e.g., 
when the item in question is not military or dual- 
use and/or is widely available from foreign 
sources). In other cases, an export license must be 
applied for from either the State Department or the 
Commerce Department, depending on the nature 
of the item. In general, the State Department’s li¬ 
censing requirements are more stringent and 
broader in scope. 39 

Software and hardware for robust, user-con- 
trolled encryption are under State Department 
control, unless State grants jurisdiction to Com¬ 


merce. This has become increasingly controver¬ 
sial, especially for the information technology and 
software industries. 40 The impact of export con¬ 
trols on the overall cost and availability of safe¬ 
guards is especially troublesome to business and 
industry at a time when U.S. high-technology 
firms find themselves as targets for sophisticated 
foreign-intelligence attacks and thus have urgent 
need for sophisticated safeguards that can be used 
in operations worldwide, as well as for secure 
communications with overseas business partners, 
suppliers, and customers. 41 Software producers 
assert that, although other countries do have ex¬ 
port and/or import controls on cryptography, sev¬ 
eral countries have more relaxed export controls 
on cryptography than does the United States. 42 

On the other hand, U.S. export controls may 
have substantially slowed the proliferation of 
cryptography to foreign adversaries over the 
years. Unfortunately, there is little public explana¬ 
tion on the degree of success of these export con¬ 
trols 43 and the necessity for maintaining strict 
controls on strong encryption 44 in the face of for- 


39 Ibid., pp. 150-154. 

40 To ease some of these burdens, the State Department announced new licensing procedures on Feb. 4,1994. These changes were expected 
to include license reform measures for expedited distribution (to reduce the need to obtain individual licenses for each end user), rapid review of 
export license applications, personal-use exemptions for U.S. citizens temporarily taking encryption products abroad for their own use, and 
special licensing arrangements allowing export of key-escrow encryption products (e.g., EES products) to most end users. At this writing, expe- 
dited-distribution reforms were in place {Federal Register , Sept. 2,1994, pp. 45621-45623), but personal-use exemptions were still under con¬ 
tention (Karen Hopkinson, Office of Defense Trade Controls, personal communication, Mar. 8, 1995). 

41 See, e.g., U.S. Congress, House of Representatives, Subcommittee on Economic and Commercial Law, Committee on the Judiciary, The 
Threat of Foreign Economic Espionage to U.S. Corporations, hearings, 102d Congress, 2d sess., Apr. 29 and May 7,1992, Serial No. 65 (Wash¬ 
ington, DC: U.S. Government Printing Office, 1992). See also discussion of business needs and export controls in chapter 3 of this background 
paper. 

42 OTA, op. cit., footnote 4, pp. 154-160. Some other countries do have stringent export and/or import restrictions. 

43 For example, the Software Publishers Association (SPA) has studied the worldwide availability of encryption products and, as of October 
1994, found 170 software products (72 foreign, 98 U.S.-made) and 237 hardware products (85 foreign, 152 U.S.-made) implementing the DES 
algorithm for encryption. (Trusted Information Systems, Inc. and Software Publishers Association, Encryption Products Database Statistics, 
October 1994.) Also see OTA, op. cit., footnote 4, pp. 156-160. 

44 For a discussion of export controls and network dissemination of encryption technology, see Simson Garfinkle, PGP: Pretty Good Priva¬ 
cy (Sebastopol, CA; O’Reilly and Assoc., 1995). PGP is a public-key encryption program developed by Phil Zimmerman. Variants of the PGP 
software (some of which infringe the RS A patent in the United States) have spread worldwide over the Internet. Zimmerman has been under 
grand jury investigation since 1993 for allegedly breaking the munitions export-control laws by permitting the software to be placed on an 
Internet-accessible bulletin board in the United States in 1991. (See Vic Sussman, “Lost in Kafka Territory,” U.S. News and World Report, Apr. 
3, 1995, pp. 30-31.) 
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eign supply and networks like the Internet that 
seamlessly cross national boundaries. 

Appendix C drawn from the 1994 OTA report, 
provides more background on export controls on 
cryptography. In September 1994, after the OTA 
report had gone to press, the State Department an¬ 
nounced an amendment to the regulations imple¬ 
menting section 38 of the Arms Export Control 
Act. 45 The new rule implements one of the re¬ 
forms applicable to encryption products that were 
announced on February 4, 1994 by the State De¬ 
partment (see footnote 47 below and also chapter 
4 of the 1994 OTA report). It established a new li¬ 
censing procedure to permit U.S. encryption 
manufacturers to make multiple shipments of 
some encryption items covered by Category 
XIII(b)(l) of the Munitions List (see appendix C) 
directly to end users in approved countries, with¬ 
out obtaining individual licenses. 46 Other an¬ 
nounced reforms, still to be implemented, include 
special licensing procedures allowing export of 
key-escrow encryption products to “most end us¬ 
ers.” 47 The ability to export strong, key-escrow 
encryption products would presumably increase 
the appeal of escrowed-encryption products to pri¬ 
vate sector safeguard developers and users. 

In the 103d Congress, legislation intended to 
streamline export controls and ease restrictions on 
mass-market computer software, hardware, and 
technology, including certain encryption soft¬ 
ware, was introduced by Representative Maria 
Cantwell (H.R. 3627) and Senator Patty Murray 
(S. 1846). In considering the Omnibus Export Ad¬ 
ministration Act of 1994 (H.R. 3937), the House 


Committee on Foreign Affairs reported a version 
of the bill in which most computer software (in¬ 
cluding software with encryption capabilities) 
was under Commerce Department controls and in 
which export restrictions for mass-market soft¬ 
ware with encryption were eased. In its report, the 
House Permanent Select Committee on Intelli¬ 
gence struck out this portion of the bill and re¬ 
placed it with a new section calling for the 
President to report to Congress within 150 days of 
enactment, regarding the current and future in¬ 
ternational market for software with encryption 
and the economic impact of U.S. export controls 
on the U.S. computer software industry. 44 

At the end of the 103d Congress, the omnibus 
export administration legislation had not been en¬ 
acted. Both the House and Senate bills contained 
language calling for the Clinton Administration to 
conduct comprehensive studies on the interna¬ 
tional market and availability of encryption 
technologies and the economic effects of U.S. ex¬ 
port controls. In a July 20, 1994, letter to Repre¬ 
sentative Cantwell, Vice President Gore had 
assured her that the “best available resources of 
the federal government” would be used in con¬ 
ducting these studies and that the Clinton Admin¬ 
istration would “reassess our existing export 
controls based on the results of these studies.” 49 

At this writing, the Commerce Department and 
NSA are assessing the economic impact of U.S. 
export controls on cryptography on the U.S. com¬ 
puter software industry. 50 As part of the study, 
NSA is determining the foreign availability of en- 


45 Department of State, Bureau of Political-Military Affairs. 22 CFR parts 123 and 124 , Federal Register, vol. 59, No. 170, Sept. 2,1994, pp. 
45621-45623. 

46 Category Xm(b)( 1) covers “Information Security Systems and equipment, cryptographic devices, software and components specifically 
designed or modified therefore,” in particular, “cryptographic and key-management systems and associated equipment, subcomponents, and 
software capable of maintaining information or information-system secrecy/confidentiality.” 

47 Martha Harris, Deputy Assistant Secretary for Political-Military Affairs, U.S. Department of State, “Encryption—Export Control Re¬ 
form,” statement, Feb. 4, 1994. See OTA, op. cit., footnote 4, pp. 159-160. 

48 A study of this type (see below) is expected to be completed in mid-1995. 

49 Vice President A1 Gore, letter to Representative Maria Cantwell, July 20, 1994. See OTA, op. cit., footnote 4, pp. 11-13. 

50 Maurice Cook, Bureau of Export Administration, Department of Commerce, personal communication, Mar. 7, 1995. 
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cryption products. The study is scheduled to be 
delivered to the National Security Council (NSC) 
by July 1. 1995. According to the Council, it is an¬ 
ticipated that there will be both classified and un¬ 
classified sections of the study; there may be some 
public release of the unclassified material. 51 In 
addition, an ongoing National Research Council 
study that would support a broad congressional re¬ 
view of cryptography (and that is expected to ad¬ 
dress export controls) is due to be completed in 
1996. 52 At this writing, the NRC study committee 
is gathering public input on cryptography issues. 

In the 104th Congress, Representative Toby 
Roth has introduced the “Export Administration 
Act of 1995” (H.R. 361). This bill does not in¬ 
clude any specific references to cryptography; at 
this writing, it is not clear whether or when the 
contentious issue of cryptography export controls 
will become part of legislative deliberations. Al¬ 
ternatively, the Clinton Administration could ease 
export controls on cryptography without legisla¬ 
tion. As was noted above, being able to export 
key-escrow encryption products would presum¬ 
ably make escrowed-encryption products more at¬ 
tractive to commercial developers and users. 
Therefore, the Clinton Administration could ease 
export requirements for products with integrated 
key escrowing as an incentive for the commercial 
development and adoption of such products (see 
discussion of cryptography initiatives in chapter 

4). 

I Overview of Issues and Options 

As noted above, the 1994 OTA report Information 
Security and Privacy in Network Environments 
focuses on three sets of policy issues: 

1. national cryptography policy, including federal 
information processing standards and export 
controls; 

2. guidance on safeguarding unclassified in¬ 
formation in federal agencies; and 


3. legal issues and information security, including 
electronic commerce, privacy, and intellectual 
property. 

Appendix E of this paper, based on chapter 1 of 
the 1994 report, reviews the set of policy options, 
about two dozen, developed by OTA. The need for 
openness, oversight, and public accountability — 
given the broad public and business impacts of 
these policies—runs throughout the discussion of 
possible congressional actions. 

Two key questions underlying consideration of 
many of these options—in particular, those ad¬ 
dressing cryptography policy and unclassified in¬ 
formation security within the federal government 
are: 

1. How will we as a nation develop and main¬ 
tain the balance among traditional “na¬ 
tional security” (and law enforcement) 
objectives and other aspects of the public in¬ 
terest, such as economic vitality, civil liber¬ 
ties, and open government? 

2. What are the costs of government efforts to 
control cryptography and who will bear 
them? 

Some of these costs—for example, the incremen¬ 
tal cost of requiring a “standard” solution that is 
less cost-effective than the “market” alternative in 
meeting applicable security requirements—may 
be relatively easy to quantify, compared with oth¬ 
ers. But none of these cost estimates will be easy 
to make. Some costs may be extremely difficult to 
quantify, or even to bound—for example, the im¬ 
pact of technological uncertainties, delays, and 
regulatory requirements on U.S. firms’ abilities to 
compete effectively in the international market¬ 
place for information technologies. Ultimately, 
however, these costs are all borne by the public, 
whether in the form of taxes, product prices, or 
foregone economic opportunities and earnings. 


51 Bill Clements, National Security Council, personal communication. Mar. 21, 1995. 

52 For information about the NRC study, which was mandated by Public Law 103-160. contact Herb Lin, National Research Council, 2101 
Constitution Avenue, N.W., Washington, DC, 20418 (crypto@nas.edu). See discussion in chapter 1 and 4 of OTA, op. cit., footnote 4. 


Digest of 
OTA Workshop 
Discussion 


A t the request of the Senate Committee on Governmental 
Affairs, the Office of Technology Assessment (OTA) held 
a workshop titled “Information Security and Privacy in 
Network Environments: What Next?” on December 6, 
1994, as part of its follow-on activities after the release of the re¬ 
port Information Security and Privacy in Network Environ¬ 
ments. 1 The puipose of the workshop was to hear the reactions 
from the business and network-user communities to the issues 
OTA had identified, as well as their priorities for any government 
actions. This chapter will review the workshop discussion and 
identify major themes that emerged, particularly regarding export 
controls and the business environment, federal cryptography 
policy, and characteristics of information-security “best prac¬ 
tices” that are germane to consideration of government informa¬ 
tion security. 

OVERVIEW 

Workshop participants came from the business, legal, university, 
and public-interest communities. Individuals’ areas of experi¬ 
ence and expertise included computer, telecommunication, and 
security technologies; information-security education and prac¬ 
tice in the private and public sectors; management; and law. 
About half of the 20 participants had prior involvement with the 
1994 OTA security and privacy report, as advisory panel mem¬ 
bers for the assessment, workshop participants, and/or reviewers. 



1 U.S. Congress, Office of Technology Assessment, Information Security and Privacy 
in Network Environments, OTA-TCT-606 (Washington, DC: U.S. Government Printing 
Office, September 1994). 
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The workshop participants also served as exter¬ 
nal reviewers for this background paper. The 
workshop participants do not, however, necessar¬ 
ily approve, disapprove, or endorse this back¬ 
ground paper. OTA assumes full responsibility 
for the background paper and the accuracy of its 
contents. 

One workshop objective was to gauge partici¬ 
pants’ overall reactions to the 1994 OTA report on 
security and privacy. Another objective was to 
identify related topics that merited attention and 
that OTA had not already addressed (e.g., network 
reliability and survivability, or “corporate” pri¬ 
vacy—see below). However, the intent of the 
workshop was not to rehash the issues and contro¬ 
versies described in the report, but rather to build 
on the report and push beyond it. A goal for the 
workshop was for participants to identify—as 
specifically as possible—areas ripe for congres¬ 
sional action. 

To spark their thinking and help focus the day’s 
discussion, participants received a set of discus¬ 
sion topics and questions in advance (see box 3-1), 
along with a copy of the 1994 report. The general 
areas of interest were: 

1. the marketplace for information safeguards and 
factors affecting supply and demand; 

2. information-security “best practices” in the pri¬ 
vate sector, including training and implementa¬ 
tion, and their applicability to government 
information security; 

3. the impacts of federal information-security and 
policies on business and the public; and 

4. desirable congressional actions and suggested 
time frames for any such actions. 

The spirited and lively workshop discussion 
identified linkages among a wide variety of the 
topics and questions posed by OTA. The range of 
discussion included cryptography policies (espe¬ 
cially export controls on cryptography), informa¬ 
tion security in the private sector, privacy 
protections, safeguarding proprietary information 
and intellectual property, and business needs in 
the international marketplace. 

OTA has identified some themes from the day’s 
discussion that have particular significance, espe¬ 


cially in the context of current developments, for 
congressional consideration of information-secu¬ 
rity issues and options identified in the 1994 OTA 
report. These themes, which are explored in chap¬ 
ter 4 of this background paper, include: 

■ the mismatch between the domestic and in¬ 
ternational effects of current U.S. export con¬ 
trols on cryptography and the needs of business 
and user communities in an international econ¬ 
omy; 

■ the intense dissatisfaction on the part of the pri¬ 
vate sector with the lack of openness and prog¬ 
ress in resolving cryptography-policy issues; 

■ the mismatch between the federal standards 
process for cryptography-related federal in¬ 
formationprocessing standards (FIPS) and pri¬ 
vate sector needs for exportable, cost-effective 
safeguards; 

■ the mismatch between the intent of the Com¬ 
puter Security Act and its implementation; 

■ the distinction between security policies and 
guidelines for implementing these policies; 

■ the need for technological flexibility in imple¬ 
menting security policies; and 

■ the need for line management accountability 
for, and commitment to, good security, as op¬ 
posed to “handing off’ security to technology 
(i.e., hoping that a “technological fix” will be 
a cure-all). 

The remainder of this chapter highlights major 
points and opinions expressed by the workshop 
participants, while attempting to convey a sense 
of the variety of positions propounded. It is impor¬ 
tant to note that this presentation is not intended to 
represent conclusions reached by the participants; 
moreover, the reader should not infer any general 
consensus, unless consensus is specifically noted. 

I Cryptography Policy 
and Export Controls 

The need for reform of export controls was the 
number one topic at the workshop and perhaps the 
only area of universal agreement. Participants ex¬ 
pressed great concern that the current controls are 
impeding companies’ implementation of good se¬ 
curity in worldwide operations and harming U.S. 
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BOX 3-1: Areas of Inquiry for Workshop 


The marketplace for information safeguards (supply and demand) 

.What factors and considerations affect the demand for and supply of safeguard tools? 

.With respect to personal privacy, are database owners/custodians and information system administra¬ 
tors sufficiently willing and able to protect privacy? 

.Is there a market failure that requires government intervention? 

Information-security “best practice,” training, and technology tools 

.What is the state of “best practice’’ in information security (and implications for agencies and Office of 
Management and Budget guidance)? 

.Security training and awareness. 

.Technology tools for securing networks and data. 

Impacts of federal policies on business and the public 

.What is the likely impact of federal policies and initiatives on business? On agency operations and in¬ 
teractions with the private sector? 

.Impact of cryptography policies on business. 

.Electronic commerce and contracts. 

What should Congress do-and when? 

.Prioritization of problem areas or needs identified in discussion. 

.Is there a possible problem of “having the tail wag the dog”? 

.What are specific solutions for high-priority problems/needs? 


firms’ competitiveness in the international mar¬ 
ketplace. More than one participant considered 
that what is really at stake is loss of U.S. leader¬ 
ship in the information technology industry. As 
one participant put it, the current system is “a mar¬ 
ket intervention by the government with unin¬ 
tended bad consequences for both government 
and the private sector.” 

U.S. export policy restrictions on products im¬ 
plementing the Data Encryption Standard (DES) 
and/or the Rivest-Shamir-Adleman (RSA) algo¬ 
rithm are viewed by several participants as anti¬ 
competitive and likely to stall U.S. information 
technology, because they frustrate both the mul¬ 
tinational companies’ need to communicate se¬ 
curely worldwide and the U.S. vendors who 
furnish secure communication products. Multina¬ 
tionals are forced to go elsewhere and have suppli¬ 
ers build for them abroad, while U.S. vendors face 
an artificially limited market. (These products can 


then be used overseas and also be imported for use 
in the United States.) 

Several participants asserted that U.S. export 
controls have failed at preventing the spread of 
cryptography, because DES- and RSA-based en¬ 
cryption, among others, are available outside of 
this country. They noted that the only “success” of 
the controls has been to prevent major U.S. soft¬ 
ware companies from incorporating high-quality, 
easy-to-use, integrated cryptography in their 
products. Many participants also viewed export 
controls as the single biggest obstacle to establish¬ 
ing international standards for information safe¬ 
guards; one noted the peculiarity of picking a 
national standard and then trying to restrict its use 
internationally. 

Participants also expressed frustration with the 
lack of a timely, open, and productive dialogue be¬ 
tween government and the private sector on cryp¬ 
tography issues and the lack of response by 
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government to what dialogue has taken place. 2 
Many stressed the need for a genuine, open dia¬ 
logue between government and business, with 
recognition that business vitality is a legitimate 
objective. Participants noted the need for Con¬ 
gress to broaden the policy debate about cryptog¬ 
raphy, with more public visibility and more 
priority given to business needs and economic 
concerns. In the export control arena, Congress 
was seen as having an important role in getting 
government and the private sector to converge on 
some feasible middle ground (legislation would 
not be required, if export regulations were 
changed). Leadership and timeliness (“the prob¬ 
lem won’t wait”) were viewed as priorities, rather 
than more studies and delay. 

Some participants also noted the importance of 
increased oversight of the Computer Security Act 
of 1987 (Public Law 100-235), as well as possible 
redirection of National Institute of Standards and 
Technology (NIST) activities (e.g., collecting in¬ 
formation about what industry is doing, pointing 
out commonalities and how to interoperate, rather 
than picking out a “standard”). 

INFORMATION SECURITY IN 
THE PRIVATE SECTOR 

The workshop discussion emphasized active risk 
acceptance by management and sound security 
policies as key elements of good information-se¬ 
curity practice in the private sector. The concept of 
management responsibility and accountability as 
integral components of information security, rath¬ 
er than just “handing off’ security to technology, 
was noted as very important by several partici¬ 
pants. Sound security policies as a foundation for 
good practice were described as technology neu¬ 
tral, consistent across company cultures, mini¬ 
malist, and as absolutes. Much was made of 
technology-neutral policies because properly ap¬ 
plied, they do not prescribe implementations, are 
not easily obsoleted by changes in technology or 
business practices, and allow for local customiza¬ 


tion of implementations to meet operational re¬ 
quirements. 

I Information-Security Policies 
and “Best Practices” 

There was general agreement that direct support 
by top management (e.g., the chief executive offi¬ 
cer and board of directors of a corporation) and up¬ 
per-management accountability are central to 
successful implementation of security policy. 
Many participants felt that tying responsibility for 
the success of security policies—and for the con¬ 
sequences of security incidents—to upper man¬ 
agement is critical. Many considered it vital that 
the managers not be insulated from risk. Accord¬ 
ing to one participant, it is important to educate 
managers on active risk acceptance; another sug¬ 
gested that their divisions could be held financial¬ 
ly responsible for lost information. 

In some of the companies represented, security 
policy has been refined to the point of “Thou shalt 
. . . not how thou shalt.” Security managers are 
charged with developing something resembling 
the “Ten Commandments” of security. Important¬ 
ly, these are not guidelines for implementation. 
Rather, they are “minimalist” directives that out¬ 
line what must happen to maintain information se¬ 
curity, but not how it must be achieved. 

One of the most important aspects about these 
policies is that they are consistent across the entire 
company; regardless of the department, informa¬ 
tion-security policies are considered universally 
applicable. The policies have to be designed in a 
broad enough fashion to ensure that all company 
cultures will be able to comply. Broad policy out¬ 
lines allow information to flow freely between 
company divisions without increased security 
risk. 

The workshop discussion noted the importance 
of auditing security implementation against 
policy, not against implementation guidelines. 
Good security policies must be technology neu¬ 
tral, so that technology upgrades and different 


2 See ibid., pp. 11-13, 150-160, and 174-179. 
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equipment in different divisions would not affect 
implementation. Ensuring that policies are tech¬ 
nology-neutral helps prevent confusing imple¬ 
mentation techniques and tools (e.g., use of a 
particular type of encryption or use of a computer 
operating system with a certain rating) with policy 
objectives, and discourages “passive risk accep¬ 
tance” like mandating use of a particular tech¬ 
nology. This also allows for flexibility and 
customization. 

Workshop participants noted that, although the 
state of practice in setting security policy often has 
not lived up to the ideals discussed above, many 
companies are improving. At this point there are 
several roadblocks frustrating more robust securi¬ 
ty for information and information systems. The 
primary roadblock is cost. Many systems are not 
built with security in mind, so the responsibility 
falls on the end user and retrofitting a system with 
security can be prohibitively expensive. 

Availability of Secure Products 

The question of the availability of secure products 
generated some disagreement over whether the 
market works or, at least, the extent to which it 
does and does not work. As described above, there 
was consensus that export controls and other gov¬ 
ernment policies that segmented market demand 
were undesirable interventions. Though the feder¬ 
al government can use its purchasing power to sig¬ 
nificantly influence the market, most participants 
felt that this sort of market intervention would not 
be beneficial overall. Many felt the market will 
develop security standards and secure systems if 
left to its own devices; others took issue with this 
position. 

Some participants said there arc problems in 
the marketplace. They asserted that many comput¬ 
er products are not designed with security in mind 
and cannot be made secure easily or cheaply. In 
particular, the UNIX operating system and the In¬ 
ternet architecture were cited as examples of prod¬ 
ucts designed without “built-in” security. Some 
suggested that today’s fierce price competition 
forces product vendors to disregard security fea¬ 
tures in favor of cost savings, leaving the purchas¬ 


er to add security to the system retroactively, at a 
much higher cost. 

The perceived propensity for security to be def¬ 
erred in order to cut costs had one or two partici¬ 
pants questioning the ability of the market to 
develop reasonably priced secure products for in¬ 
formation systems and whether government ac¬ 
tion is needed to lead the market in the “right” 
direction—for example, through standards for 
federal procurements or regulations setting base¬ 
line product requirements. Though most partici¬ 
pants seemed to agree that many products have 
been built without security features and that retro¬ 
fitting a system with security is expensive and dif¬ 
ficult, there was strong sentiment from industry 
representatives that the market should be left 
alone. Many participants described government 
interventions into the market, such as export con¬ 
trols and the Escrowed Encryption Standard 
(EES, or Clipper), as economically detrimental, 
and saw nothing to indicate that interventions 
would be more beneficial in the future. 

Some pointed out a distinction between the 
ability of large businesses and small businesses to 
purchase products that incorporate security. Large 
businesses are able to demand more security fea¬ 
tures because of the size of their operations; while 
smaller companies must often individually pur¬ 
chase and configure a basic product, which may 
have been designed without security in mind. 

Implicit in the discussion of the ability of the 
market to produce secure products is the extent of 
demand for them. Those arguing that market 
forces will develop secure systems stated, basical¬ 
ly, that when buyers demand secure products, se¬ 
cure products will be available. Participants from 
vendor companies were especially adamant about 
the strength of the relationship between them¬ 
selves and the industry users. (One example of 
user efforts to work with vendors to develop more 
security-oriented products is a group called Open 
User Recommended Solutions (OURS), which 
has recently developed a single sign-on product 
description.) Those who felt the market will not 
develop secure products in the near future feel that 
the demand for inexpensive products will con- 
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tinue to outweigh demand for security, and/or 
noted the demand-segmenting effects of export 
controls. 

Some participants pointed out that the reason 
security concerns defer to price concerns is the in¬ 
ability to quantify the value of good security. 
Some noted this as a prevalent problem when at¬ 
tempting to convince upper management of the 
need for security. Lack of reported breaches, the 
inability to evaluate successful security, and the 
lack of a direct cost/benefit analysis all lead to an 
unclear assessment of need. This in turn reduces 
the demand, which drives the market to ignore se¬ 
curity. 

Training 

Most security managers participating in the work¬ 
shop viewed training as vital to any successful in- 
formation-security policy. Lack of training leads 
to simple errors potentially capable of defeating 
any good security system—for example, em¬ 
ployees who write their passwords on paper and 
tape it to their computers. Several participants 
knew of companies that have fallen into the 
technology trap and have designed excellent com¬ 
puter security systems without sufficiently em¬ 
phasizing training. 

There is a core of training material that is 
technology neutral and ubiquitous across the com¬ 
pany. Some companies develop elaborate video 
presentations to ensure that training is consistent 
throughout the various company cultures. Some 
participants felt that employees must be trained in 
technology; believing that, if users do not under¬ 
stand the technologies they have incorporated into 
their business, then they will be pressed to do what 
is necessary to implement security policies. 

The necessity for impressing upon employees 
their role in information security is paramount. 
Because the average individual tends to not recog¬ 
nize the importance of training, it falls to manage¬ 
ment to demonstrate its value. To this end, several 
participants emphasized the importance of dem¬ 
onstrating the value of training to management. 


Many felt that much of the responsibility for get¬ 
ting management interested in training rested with 
the program manager. Like other elements of in¬ 
formation security, financial departments have 
difficulty quantifying the value of training. Some 
point out that “an insurance” policy is a poor mod¬ 
el, because there are no guarantees, nor are the 
risks easily quantifiable. Some suggested it will 
take a crisis to convince upper management of the 
need to effectively train employees and that anec¬ 
dotal evidence is the best tool in the absence of 
hard definable numbers. This view was not uni¬ 
versally accepted. 

Common Themes 

A common thread to the discussion of informa¬ 
tion-security practices is the necessity for a 
heightened awareness of security needs by upper 
management. Making management aware of the 
danger of and propensity for financial loss due to 
lax security is vital to security policy, product 
availability, and the training issue. Some partici¬ 
pants felt that the inability to set up a cost justifica¬ 
tion formula for information security is a major 
impediment to convincing management of the 
need for it. In addition, the difficulty in evaluating 
the success of a security program limits a security 
officer in making a case to management. 

A proposed solution to this problem is the es¬ 
tablishment of an agreed-upon body of knowledge 
or “common checklist” for security officers to 
compare their company policies against. There is 
a large core of commonality in security awareness, 
training, and education. If made legally binding, 
or part of industry consensus as to what consti¬ 
tutes “prudent practice,” such a checklist would 
also tie directly into the liability issues as well as a 
host of other problems facing companies. For ex¬ 
ample, when organizations outsource, contractual 
specifications are needed to ensure adequate secu¬ 
rity coverage. If there were a well-known and ac¬ 
cepted “common checklist” for security, then it 
would be easier to develop contractual specifica- 
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tions without revealing too much of your opera¬ 
tions or levels of security to the contractor. 

I Domestic and International 
Privacy Issues 

Consumers arc increasingly concerned with con¬ 
trol of personal and transactional data and are 
seeking some protection from potential abuse of 
this information. Those participants who had been 
less inclined than most to trust the market on secu¬ 
rity issues found more comfortable ground on pri¬ 
vacy, because few participants seemed to feel that 
the market will prioritize personal privacy. 

The discussion of privacy protection was less 
extensive than some other topics covered during 
the workshop. Opinions were split on whether 
new privacy legislation and/or a privacy commis¬ 
sion was desirable. There was a general feeling 
that individuals should be protected from abuses 
incurred by access to their personal data (e.g., 
transactional data or “data shadows” that could be 
reused or sold like a subscribers list), but many 
were concerned about limiting business opportu¬ 
nities through new controls. 

Some participants pointed out that the global¬ 
ization of the information infrastructure will in¬ 
crease consumer privacy concerns and present 
security questions (e.g., nonrepudiation of trans¬ 
actions) in home-based applications. One partici¬ 
pant recommended a close reading of the 
Canadian privacy policy as a possible guide for 
our government. 3 The concepts of a Privacy Com¬ 
mission or a privacy “Bill of Rights” were also 
brought up as omnibus solutions, but specifics re¬ 
garding how they might protect personal privacy 
were not examined. 

One of the umbrella points of the privacy de¬ 
bate that most participants agreed to is the need for 
a “trusted” infrastructure capable of supporting 


global transactions and trade based on a firm set of 
ground rules and fair information practices. This 
trusted infrastructure must support authentication 
and allow secure transactions. To be implemented 
such an infrastructure will have to resolve liabil¬ 
ity 4 and conditional access issues and develop a 
system of certification controls. Today, differ¬ 
ences between the levels of privacy protection in 
the United States and those of its trading partners, 
which in general protect privacy more rigorously, 
could also inhibit development of this infrastruc¬ 
ture. 

Some participants felt that the common rules of 
the road for a trusted infrastructure could be the re¬ 
sponsibility of a U.S. Privacy Commission. Many 
of these felt that a close look at the European pri¬ 
vacy system would be helpful in establishing 
guidelines (being the “last ones on the block” to 
open a Privacy Commission, the United States 
should not try to set the standard, but should build 
on the European Union model). Unfortunately, 
one participant noted, this is a 20-year-old discus¬ 
sion, and as much as industry would like a com¬ 
mon set of rules with the European Union, he felt 
that it is unlikely they will get it in the near future. 

I Proprietary Information and 
Intellectual Property 

A major concern raised by industry participants 
was the need to protect intellectual property and 
proprietary information in electronic form. Com¬ 
panies need to protect their information and trans¬ 
mit it to business partners and offices here and 
abroad. In light of what many perceived as a grow¬ 
ing problem, several individuals recommended a 
reexamination of “information rights” (e.g., intel¬ 
lectual property rights, confidentiality for propri¬ 
etary information) in light of the recent changes in 
information storage and data collection methods 


3 See Industry Canada, Privacy and the Canadian Information Highway (Ottawa, Ontario: Minister of Supply and Services Canada, 1994), 
available by WWW from http://debra.dgbt.doc.ca/isc/isc.html. See also Canadian Standards Association, “Model Code for the Protection of 
Personal Information,” CAN/CSA-Q830-1994, draft, November 1994. 

4 For a discussion, see Michael S. Baum, Federal Certification Authority Liability and Policy, NIST-GCR-94-654, NTIS Doc. No. 
PB94-191-202 (Springfield, VA: National Technical Information Service, 1994). 
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that allow information to be readily copied, aggre¬ 
gated, and manipulated. 

Some participants felt that confidentiality of 
company information could be adequately ad¬ 
dressed with better corporate security policies. 
For example, it may be more difficult to prosecute 
(or deter) an intruder if a company’s log-on screen 
says “Welcome to Company X” instead of provid¬ 
ing a clear statement to inform individuals of the 
company’s intent to prosecute if information on 
the system is misused or accessed without autho¬ 
rization. 

Several participants raised the issue of “corpo¬ 
rate privacy” regarding to information not pro¬ 
tected by intellectual property laws. Many felt 
corporations need legal protection for “private” 
information—that is, information that is propri¬ 
etary to the corporation, but does not qualify for 
protection under copyright, patent, or trade secret 
laws. 5 Though some privacy advocates balk at the 
concept of “corporate privacy,” 6 several partici¬ 
pants felt that a set of standards protecting re¬ 
search and other proprietary information were 
important to both information security and contin¬ 
ued product development. The issue of “corporate 
privacy” was also raised regarding legal discov¬ 
ery. A few individuals expressed concern over the 
expense corporations face complying with dis¬ 
covery motions during litigation (e.g., with re¬ 
spect to email and electronic records), but this 
topic was not explored at length during the day’s 
discussion. 


Patent issues and confidentiality of lab docu¬ 
ments were of major concern to individuals in¬ 
volved in research and development. They saw a 
need for evidentiary rules in electronic environ¬ 
ments to prevent research fraud, to ensure that 
electronic lab notebooks are a permanent, enforce¬ 
able record, and to prosecute intruders. 

There was some discussion regarding whether 
new laws are needed to protect information re¬ 
sources from computer crime—or whether better 
enforcement is the solution. Some felt that the le¬ 
gal system is not in tune with the new world of 
computer crime; a world where the computer is 
the instrument not the target of the crime. Some 
also felt that the legal profession may not be famil¬ 
iar with “authentication” in electronic environ¬ 
ments. Others felt that enforcement is the 
problem, not the laws. This topic was not ex¬ 
amined at length and no consensus was reached. 

The question of liability standards for a compa¬ 
ny in possession of personal data was brought up 
as an issue in need of a solution. One participant 
made an urgent plea for a rapid definition of basic 
legal requirements, to prevent costly retrofitting 
to meet security and privacy requirements that 
could be imposed later on. Some believe there 
should be true and active participation at the feder¬ 
al, state, and local levels to develop consensus on 
new principles of “fair information practices” 7 
that would take into account the ways businesses 
operate and be flexible enough to meet the needs 


5 George B Trubow, Whether and Whither Corporate Privacy, essay based on an article prepared for the “DataLaw Report" Gtru- 
bow@jmls.edu. 

6 “The scope of these laws should be limited to the protection of the privacy of personal information; they should not be extended to cover 
legal persons. Issues relating to companies, such as providing adequate protection for corporate proprietary information, are different and 
should be the subject of a different body of law.” (Business Roundtable, “Statement on Transborder Data Flow—on Privacy and Data Protec¬ 
tion,” in L. Richard Fischer (ed.), The Law of Financial Privacy, A Compliance Guide , 2nd Ed. (New York, NY: Warren, Gorham & Lamont, 
1991), appendix 6.3, p. 6-93.) 

7 For example, the Privacy Act of 1974 (Public Law 93-579) embodied principles of fair information practices set forth in Computers and 
the Rights of Citizens, a report published in 1973 by the former U.S. Department of Health, Education, and Welfare. Those principles included 
the requirement that individuals be able to discover what personal information is recorded about them and how it is used, as well as be able to 
correct or amend information about themselves. Other principles included the requirement that organizations assure the reliability of personal 
data for its intended use and take reasonable precautions to prevent misuse. The Privacy Act is limited to government information collection and 
use. It approaches privacy issues on an agency-by-agency basis and arguably does not address today’s increased computerization and linkage 
of information. See OTA, op. cit., footnote 1, ch. 3. 
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of various types of individuals and organizations, 
but that would also offer some stability (or, “safe 
havens”) for new lines of business by delineating 
acceptable forms of information collection and 
use. Others did not see a need for omnibus privacy 
codes or legislation, preferring to deal with prob¬ 
lems on an industry-by-industry basis. 

As part of the question of liability, it was noted 
that the tension between network providers and 
users continues to be unresolved. The dilemma 
exists between the network providers’ inability to 
monitor content (e.g., invasion of privacy), while 
at the same time being held responsible for the 
content of material transferred over their services. 
One suggestion was to treat network providers 
more like public utilities and less like publishers. 

I Views on Congressional Action 

This section outlines suggestions made for gov¬ 
ernment action, particularly by Congress. It does 
not represent the consensus of the participants at 
the workshop; it only isolates areas that were dis¬ 
cussed and lists possible solutions generated dur¬ 
ing the discussion. 

Cryptography Policy and Export Controls 

A near consensus was reached regarding the EES 
(Clipper chip). The vast majority felt that it was 
poorly handled, poorly conceived, and did not 
take into account the structure of today’s world 
economy. It is a national standard in an interna¬ 
tional economy. It will exacerbate the problems 
with export controls, by having one system (EES) 
in the United States and one system (DES or 
another system) outside the United States. Many 
felt that it is an enormous distraction that, coupled 
with export controls, will allow foreign countries 
to get ahead of us in the global information infra¬ 
structure. 

Several participants felt that the United States 
is getting out of step with the international com¬ 
munity, and appears pointed in the wrong direc¬ 
tion on information security. Many industry 
representatives feel that the potential of U.S. poli¬ 
cies to damage the economy and U.S. industry is 


not being given priority by the people making de¬ 
cisions. 

Possible Congressional Actions: 

■ Review export controls and find a feasible 
middle ground. 

■ Review the executive decision on the Clipper 
chip. 

■ Promote consumer use of a public-key infra¬ 
structure. 

■ Open up a public dialogue with NIST, the Na¬ 
tional Security Agency (NSA), and the Federal 
Bureau of Investigation (FBI) on the interna¬ 
tional availability of cryptography. 

■ State that the international competitiveness of 
the United States in information systems and 
communications is a priority in considering 
cryptography policy. 

Federal Standards and Open Dialogue 

There was a general consensus on the need for 
ground rules and standards for safeguarding in¬ 
formation, but much disagreement on how this 
should be done. There was sentiment that leader¬ 
ship is needed from the government on these is¬ 
sues. However, many participants did not think 
the government should or could set these stan¬ 
dards. Many felt the information-policy branches 
of the government are unable to respond adequate¬ 
ly to the current leadership vacuum; therefore, 
they felt that government should either establish a 
more effective policy system and open a construc¬ 
tive dialogue with industry or leave the problem to 
industry. 

The lack of public dialogue, visibility, and ac¬ 
countability, particularly demonstrated by the 
introduction of the Clipper chip and promulgation 
of the EES, is a constant source of anger for both 
industry representatives and public interest 
groups. 

There were many concerns and frustrations 
about the role of the National Security Agency. 
Several individuals felt that dialogue on informa¬ 
tion policy is paralyzed because NSA is not allow¬ 
ing open discussion nor responding in any 
tangible way to the needs of industry. Many par- 
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ticipants suggested that this country desperately 
needs a new vision of national security that incor¬ 
porates economic vitality. They consider that 
business strength is not part of NSA’s notion of 
“national security,” so it is not part of their mis¬ 
sion. As one participant put it, “saying that ‘we all 
have to be losers’ on national security grounds is 
perverse industrial policy.” 

The Computer Systems Security and Privacy 
Board (CSSPAB) was suggested as one stimulus 
for generating dialogue between industry and 
government, but according to several participants 
the committee is not well utilized. In addition, 
there exists an information gap: the CSSPAB was 
“kept in the dark” about the Clipper initiative, 
then after it gathered information through public 
meetings, the information and CSSPAB recom¬ 
mendations were ignored by the Commerce De¬ 
partment. 

Possible Congressional Actions: 

■ Define basic legal requirements to prevent un¬ 
necessary and retroactive security measures. 

■ Revise the export administration act in order to 
allow multinationals to set up ubiquitous secu¬ 
rity standards through U.S. vendors. 

■ Increase oversight of the Computer Security 
Act as it relates to the relationship between 
NSA and NIST and review the Memorandum 
of Understanding between NSA and NIST. En¬ 
courage more open dialogue with and utiliza¬ 
tion of the CSSPAB. 

■ Encourage NIST to develop a Certification 
Standard to support interoperability across net¬ 
works, rather than picking technological stan¬ 
dards. 

■ Redefine national security priorities. 

Information Security in Federal Agencies 

Participants suggested that there needs to be more 
emphasis on securing unclassified information 
and that there needs to be leadership. According to 
some participants: the government should get “its 
house in order” in the civilian agencies; few 
companies are so badly managed as government 
agencies; senior managers are unaware of respon¬ 
sibilities and untrained. As a result, participants 


noted, the architecture and policy constructs of the 
international information infrastructure are being 
developed right now, but these are “being left to 
the technologists” due to lack of leadership. 

Several felt that there has been overemphasis 
on cryptography, to the exclusion of management; 
severe problems like errors and dishonest em¬ 
ployees are not addressed by this “technology” fo¬ 
cus. Participants considered that the real issue is 
management ; technology sloganism along the 
lines of “buy C2 [a computer security rating] and 
you’re OK” is not enough. According to partici¬ 
pants, existing policies [e.g., the previous version 
of OMB Circular A-130, Appendix III] attempt to 
mandate cost-based models, but the implementa¬ 
tion is ineffective. For example, after the Comput¬ 
er Security Act, NIST should have been in a 
position to help agencies, but this never happened 
due to lack of resources. Civil agencies lack 
resources, then choose to invest in new applica¬ 
tions rather than spend on security. This is under¬ 
standable when the observation that “nothing 
happens”—that is, no security incidents are de¬ 
tected—is an indicator of good security. Partic¬ 
ipants observed that, if inspectors general of 
agencies are perceived as neither rewarding or 
punishing, users get mixed signals and conclude 
that there is a mismatch between security postures 
and management commitment to security imple¬ 
mentation. 

There was widespread support for the Comput¬ 
er Security Act of 1987, but universal frustration 
with its implementation. NIST, the designated 
lead agency for security standards and guidelines, 
was described as underfunded and extremely 
slow. There was also a general recognition that 
people had been complaining about NIST for a 
while, but nothing has happened as a result of 
these complaints. 

Possible Congressional Actions: 

■ Implement oversight of the Computer Security 
Act with special attention to management of in- 
formation-security policy. 

■ Fully fund NIST so it can “sort out the ‘tower 
of Babel’ in cryptographic capabilities and sys¬ 
tem interoperability.” Several participants sug- 
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gested frying to encourage better standards 
policy by using the General Accounting Office 
to audit agency compliance with NIST stan¬ 
dards, or mandating that agencies respond to 
CSSPAB recommendations. 

■ Encourage more attention to management prac¬ 
tices. Review OMB Circular A-130 with par¬ 
ticular emphasis on implementation. 

Privacy 

The privacy issue in general came up often, but no 
one had a detailed solution. There is an urgent 
sense that something needs to be done, because 
questions of personal privacy and “corporate pri¬ 
vacy” continue to cause controversy and the prob¬ 
lems will only increase as network access 
expands. The only concrete suggestion, which 
was not universally endorsed, is the creation of a 
Privacy Commission, possibly with a cabinet-lev- 
el head or as a part of the Commerce Department. 

One frequently mentioned topic was for gov¬ 
ernment recognition of U.S. industry’s need for 


consistency between U.S. privacy laws and Euro¬ 
pean privacy laws. This reflects the industry 
orientation toward the international nature of the 
economy. 

Several participants called on Congress to re¬ 
view liability issues and intellectual-property 
concerns, with respect to electronic information 
and networks. Some participants felt the need to 
protect providers from action taken over their net¬ 
works. Some suggested that network providers be 
treated more like a public utility, removed from li¬ 
ability for the content of the material carried over 
their networks. 

Possible Congressional Actions: 

■ Establish a Privacy Commission. 

■ Determine regulatory status and liability of net¬ 
work providers. 

■ Review intellectual-property laws for enforce¬ 
ment in electronic environments. 

■ Examine European Union privacy laws and re¬ 
view the possibility of bringing U.S. privacy 
protections closer to theirs. 


Implications 

for 

Congressional 

Action 


S ince the 1994 OTA report Information Security and Privacy 
in Network Environments 1 was published, security con¬ 
cerns like “sniffing” and “spoofing” by intruders, security 
holes in popular World Wide Web software, and intrusions 
into commercial and government networks have continued to re¬ 
ceive attention: 


■ Password sniffers capture legitimate users’ passwords for later 
use by intruders. Spoofing involves the use of fake origination 
addresses, so that an incoming connection will appeal - to come 
from somewhere else, usually a “legitimate” or “trusted” Inter¬ 
net network protocol (IP) address. 2 

■ The U.S. Department of Energy’s computer security response 
group alerted Internet users to, and issued corrections for, a 
flaw in a version of the free UNIX software commonly used to 
create World Wide Web “home pages.” Depending on how a 
World Wide Web server is configured, the vulnerability could 
permit a hacker to access the computer’s main, or “root” direc¬ 
tory. Commercial Web products under development (e.g., for 


1 U.S. Congress, Office of Technology Assessment, Information Security and Priva- 
cy in Network Environments, OTA-TCT-606 (Washington, DC: U.S. Government Print¬ 
ing Office, September 1994). See Congressional Record, Sept. 22, 1994, pp. S13312-13 
(statement of Senator William V. Roth, Jr. announcing release of the OTA report). 

2 See Michael Neubarth et al., “Internet Security” (special section), Internet World, 
February 1995, pp. 31-72. See also William Stallings, Network and Internetwork Securi¬ 
ty: Principles and Practice (Englewood Cliffs, NJ: Prentice Hall (IEEE Press), 1995, 
chapter 6. 
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electronic commerce) are incorporating addi¬ 
tional security features. 3 
■ During 1993-94, the Defense Information Sys¬ 
tems Agency (DISA) conducted mock attacks 
on 8,932 Defense Department computers. The 
DISA team broke into 7,860 of these, but the 
systems’ computer administrators detected 
only 390 of the successful “sting” intrusions. 
Only about 20 reported the incident. DISA esti¬ 
mates that real attacks on Defense systems av¬ 
erage about one per day. 4 
The increasing prominence of the Defense 
Department’s “Information Warfare” doctrine is 
raising awareness of threats from economic espio¬ 
nage, global organized crime, and terrorism. 5 
Awareness of technical countermeasures like 
firewalls, active intrusion-detection systems, one¬ 
time password generators, and challenge-re¬ 
sponse user authentication systems 6 continues to 
rise, although use lags for a number of reasons, in¬ 
cluding cost. 7 

This chapter provides an update of executive 
branch and private sector cryptography develop¬ 
ments, business perspectives on government poli¬ 
cies, congressional consideration of privacy 
issues, and government-wide guidance on in¬ 
formation security in the federal agencies. It also 
discusses the most recent attempts within the 
executive branch to centralize unclassified-in- 
formation-security authorities government-wide. 


The proposed “new order” presented in the Secu¬ 
rity Policy Board staff’s 1994 report (see below) 
would increase the government-wide authorities 
of the defense and intelligence agencies for un¬ 
classified information security within the federal 
government. Such an expansion of authorities 
would run counter to the unclassified-informa¬ 
tion-security structure mandated by the Computer 
Security Act of 1987 (see chapter 2 and appendix 
B), as well as the agency responsibilities set forth 
in the Paperwork Reduction Act of 1995 (see be¬ 
low) and the new, proposed revision to Appendix 
III of OMB Circular A-130 (see below). The chap¬ 
ter concludes with a discussion of the implications 
of these developments for congressional consider¬ 
ation of issues and options identified in the 1994 
OTA report Information Security and Privacy in 
Network Environments. 

UPDATE ON CRYPTOGRAPHY 
INITIATIVES 

This section highlights selected government and 
commercial cryptography developments since 
publication of the 1994 report. This is not a com¬ 
prehensive survey of commercial information-se¬ 
curity products and proposals. Mention of 
individual companies or products is for illustra¬ 
tive puiposes and/or identification only, and 


3 See Elizabeth Sikorovsky, “Energy Group Uncovers Hole in Web Software," Federal Computer Week, Feb. 20,1995, pp. 3-4; and Richard 
W. Wiggins, “Business Browser,” Internet World, February 1995, pp. 52-55. 

4 See, e.g., Jared Sandberg, “GE Says Computers Linked to Internet Were Infiltrated,” The Wall Street Journal, Nov. 28,1994; or Bob Bre- 
win and Elizabeth Sikorovsky, “DISA Stings Uncover Computer Security Flaws,” Federal Computer Week, Feb. 6, 1995, pp. 1-45. See also 
Vanessa Jo Grimm, “In War on System Intruders, DISA Calls in Big Guns,” Government Computer News, Feb. 6, 1995, pp. 41-42. 

5 See Neil Munro, “New Info-War Doctrine Poses Risks, Gains,” Washington Technology, Dec. 22, 1994, pp. 1, 12; and “How Private Is 
Your Data?” Washington Technology, Feb. 9, 1995, pp. 14, 16. 

6 Firewalls are network barriers that filter network traffic, for example, denying incoming telnet or ftp connections except to designated 
directories, from designated network domains or IP addresses. Active intrusion-detection systems look for anomalous or abnormal processes 
(like extended log-on attempts as an intruder tries to “guess” valid passwords, attempts to copy password files or system programs), curtail 
them, and alert security officers. See, e.g., Stallings, op. cit., footnote 2; Warwick Ford, Computer Communications Security (Englewood Cliffs, 
NJ: Prentice Hall, 1994); and Jeffrey I. Schiller, “Secure Distributed Computing,” Scientific American, November 1994, pp. 72-76. 

7 Recent government efforts to promote use of security technologies include several cataloging and technology transfer efforts undertaken 
by the Office of Management and Budget, National Institute of Standards and Technology, and the Defense Department. See Neil Munro, “Feds 
May Share Security Tech,” Washington Technology, Nov. 10, 1994, pp. 1, 22. 
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should not be interpreted as endorsement of these 
products or approaches. 

I Executive Branch Developments 8 

In mid-1994, the executive branch indicated an 
openness toward exploring alternative forms of 
key-escrow encryption (i.e., techniques not im¬ 
plementing the Skipjack algorithm specified in 
the Escrowed Encryption Standard (EES)) for use 
in computer and video networks. 9 However, there 
has been no formal commitment to eventually 
adopting any alternative to Skipjack in a federal 
escrowed-encryption standard for computer 
data. 10 Moreover, there has been no commitment 
to consider alternatives to the EES for telephony. 

The question of whether or when there will be 
key-escrow encryption federal information proc¬ 
essing standards (FIPS) for unclassified data com¬ 
munications and/or file encryption is still open. 
There is at present no FIPS specifying use of Skip¬ 
jack for these applications. (The EES specifies an 
implementation of Skipjack as a standard for use 
in telephone, not computer, communications.) 
However, the Capstone chip and FORTEZZA 
card implementation of the Skipjack algorithm is 
being used by the Defense Department in the De¬ 
fense Message System. 

Furthermore, there has been no backing away 
from the underlying Clinton Administration com¬ 
mitment to “escrowing” encryption keys. With es¬ 


crowing, there is mandatory key deposit. In the 
future, there may be some choice of “escrow agen¬ 
cies” or registries, but at present, EES and Cap- 
stone-chip keys are being escrowed within the 
Commerce and Treasury Departments. The notion 
of optional deposit of keys with registries, which 
OTA referred to as “trusteeship” in the 1994 report 
(to distinguish it from the Clinton Administra¬ 
tion’s concept of key escrowing being required as 
an integral part of escrowed-encryption systems), 
is not being considered. 11 

Implementation of key escrowing or trusteeship 
for large databases (i.e., encryption for file stor¬ 
age, as opposed to communications) has not been 
addressed by the government. However, commer¬ 
cial key depositories or data-recovery centers are 
being proposed by several companies (see next 
section on private sector developments). At pres¬ 
ent, there is no FIPS for secure key exchange (e.g., 
for use with the Data Encryption Standard (DES). 

Turning from encryption to digital signatures, 
acceptance and use of the new FIPS for digital sig¬ 
natures are progressing, but slowly. As the 1994 
report detailed in its description of the evolution 
of the Digital Signature Standard (DSS), patent 
problems complicated the development and pro¬ 
mulgation of the standard. 12 Patent-infringement 
uncertainties remain for the DSS, despite the gov¬ 
ernment’s insistence that the DSS algorithm does 
not infringe any valid patents and its offer to in- 


8 See also OTA. op. cit., footnote 1, pp. 171-182. 

9 For background, see appendix E of this background paper and OTA, op. cit., footnote 1. pp. 15-16 and 171-174. The Escrowed Encryption 
Standard is described in box 2-3 of this background paper. 

10 See box 2-3. The Capstone chip refers to a hardware implementation of the EES’s Skipjack algorithm, but for data communications. 
FORTEZZA (formerly TESSERA) is a PCMCIA card implementing Skipjack for data encryption, as well as the Digital Signature Standard 
(DSS—see box 2-2) and key-exchange functions. 

11 See OTA, op. cit., footnote 1, p. 171. 

12 See OTA, op. cit., footnote 1, appendix C, especially pp. 220-21. For a more recent account of the various lawsuits and countersuits among 
patentholders, licensers, and licensees, see Simson Garfinkle, PGP: Pretty Good Privacy (Sebastopol, CA: O’Reilly and Assoc., 1995), esp. ch. 
6 . 
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demnify vendors that develop certificate authori¬ 
ties for a public-key infrastructure. 13 

Plans to implement the DSS throughout govern¬ 
ment are complicated by the relatively broad pri¬ 
vate-sector use of a commercial alternative, the 
RSA signature system, and some agencies’ desire 
to use the RSA system instead of, or alongside, the 
Digital Signature Standard (DSS). For example, 
some federal agencies (e.g., the Central Intelli¬ 
gence Agency) have already purchased and imple¬ 
mented commercial software packages containing 
RSA-based security features. 14 Moreover, many 
agencies and their contractors are interested in 
software-based signature systems, rather than 
hardware-based implementations. For example, 
the Westinghouse Savannah River Company, 
which is the management and operating contrac¬ 
tor for the DOE at the Savannah River Site, is 
seeking a business partner under a cooperative re¬ 
search and development agreement (CRADA) ar¬ 
rangement for collaborative development of 
software involving application and integration of 
the DSS into business-applications software 
packages. The goal of the CRADA project is to 
produce a software product or module that can be 
used to replace paper-based approval signatures 
with digital signatures. These digital signatures 
would be used, for example, for time and atten¬ 
dance reporting, travel expense reporting, and 
other forms management and routing in local area 
networks. 15 


Cost, as well as interoperability with the private 
sector, is an issue. The DSS can be implemented in 
hardware, software, or firmware, but the National 
Security Agency’s (NSA’s) preferred imple¬ 
mentation is in the FORTEZZA card, along with 
the EES algorithm. The FORTEZZA card (for¬ 
merly called the TESSERA card) is a Personal 
Computer Memory Card Industry Association 
(PCMCIA) card. 16 The FORTEZZA card is used 
for data communications; it implements the Skip¬ 
jack algorithm, as well as key-exchange and digi¬ 
tal-signature functions. FORTEZZA applications 
include the Defense Department’s Defense Mes¬ 
sage System. Per-workstation costs are signifi¬ 
cantly higher for the FORTEZZA card than for a 
software-based signature implementation alone. 
To use FORTEZZA, agencies must have—or up¬ 
grade to—computers with PCMCIA card slots, or 
must buy PCMCIA readers (about $125 each). 

According to NSA, current full costs for FOR¬ 
TEZZA cards are about $150 each in relatively 
small initial production lots; of this cost, about 
$98 is for the Capstone chip. About 3,000 FOR¬ 
TEZZA cards had been produced as of April 1995 
and another 33,000 were on contract. NSA hopes 
to award a large-scale production contract in fall 
1995 for 200,000 to 400,000 units. In these quan¬ 
tities, according to NSA, unit costs should be be¬ 
low the $100 per unit target established for the 
program. 17 Thus, the FORTEZZA production 


13 F. Lynn McNulty et al., NIST, "Digital Signature Standard Update.” Oct. 11, 1994. The government offered to include an "authorization 
and consent” clause under which the government would assume liability for any patent infringement resulting from performance of a contract, 
including use of the DSS algorithm or public-key certificates by private parties when communicating with the government. See also OTA, op. 
cit., footnote 1, ch. 3. 

14 See Brad Bass, “Federal Encryption Policy Shifts Direction,” Federal Computer Week , Feb. 20, 1995, pp. 28-29. Lotus Notes [TM], a 
“groupware” package that has RSA public-key and access-control security features, is reportedly used to handle over 85 percent of the Central 
Intelligence Agency’s (CIA’s) email traffic. (Adam Gaffin, “CIA Espies Value in Turning to Lotus Notes ,”Network World, Mar. 13,1995, p. 43.) 

15 Commerce Business Daily, Apr. 5, 1995. 

16 PCMCIA cards are slightly larger than a credit card, with a connector on one end that plugs directly into a standard slot in a computer (or 
reader). They contain microprocessor chips; for example, the FORTEZZA card contains a Capstone chip. 

17 Bob Drake, Legislative Affairs Office, NSA, personal communication, Apr. 7, 1995. To make the apparent price of FORTEZZA cards 
more attractive to Defense Department customers in the short term, NSA is splitting the cost of the Capstone chip with them, so agencies can 
acquire the early versions of FORTEZZA for $98 apiece (ibid.). 
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contract would be on the order of $20 million to 
$40 million. 

The National Institute of Standards and 
Technology (NIST) is working on what is in¬ 
tended to become a market-driven validation sys¬ 
tem for vendors’ DSS products. This is being done 
within the framework of overall requirements de¬ 
veloped for FIPS 140-1. “Security Requirements 
for Cryptographic Modules” (January 11. 1994). 
NIST is also developing a draft FIPS for “Crypto¬ 
graphic Service Calls” that would use relatively 
high-level application program interfaces (e.g., 
“sign” or “verify”) to call on any of a variety of 
cryptographic modules. The intention is to allow 
flexibility of implementation in what NIST recog¬ 
nizes is a “hybrid world.” Unfortunately, this 
work appears to have been slowed due to the tradi¬ 
tional scarcity of funds for such core security pro¬ 
grams at NIST (see chapter 2 and the 1994 OTA 
report, pp. 20 and 164). 

Due to lack of procurement funds and to avoid 
duplicating other agencies’ operational efforts, 
NIST did not issue a solicitation for public-key 
certificate services. The U.S. Postal Service and 
the General Services Administration have at pres¬ 
ent taken the lead on a government public-key in¬ 
frastructure. 18 The 1996 Clinton Administration 
budget proposals reportedly do not specify funds 
for NIST work related to the DSS, or the EES. 19 
However, according to the draft charter of the 
Government Information Technology Services 
Public-Key Infrastructure Federal Steering Com¬ 
mittee, NIST will chair and provide administra¬ 
tive support for the Public-Key Infrastructure 
(PKI) Federal Steering Commmittee that is being 


formed to provide guidance and assistance in de¬ 
veloping an interoperable, secure public-key in¬ 
frastructure to support electronic commerce, 
electronic mail, and other applications. 

The Advanced Research Projects Agency 
(ARPA), the Defense Information Systems 
Agency, and NSA have agreed to establish an In¬ 
formation Systems Security Research Joint 
Technology Office (JTO) to coordinate research 
programs and long-range strategic planning for 
information systems security research and to ex¬ 
pedite delivery of security technologies to DISA. 
Part of the functions of JTO will be to: 

■ Encourage the U.S. industrial base to develop 
commercial products with built-in security to 
be used in Defense Department systems. De¬ 
velop alliances with industry to raise the lev¬ 
el of security in all U.S. systems. Bring 
together private sector leaders in information 
security to advise JTO and build consensus 
for the resulting program. 

■ Identify areas for which standards need to be 
developed for information systems security. 

■ Facilitate the availability and use of NSA- 
certified cryptography within information 
systems security research programs . 20 

According to the Memorandum of Agreement es¬ 
tablishing JTO, its work is intended to improve 
DISA’s ability to safeguard the confidentiality, in¬ 
tegrity, authenticity, and availability of data in De¬ 
fense Department information systems, provide a 
“robust first line of defense” for defensive in¬ 
formation warfare, and permit electronic com¬ 
merce between the Defense and its contractors. 
(See discussion of the Defense Department’s “In¬ 
formation Warfare” activities later in this chapter.) 


18 F. Lynn McNulty et al., NIST, personal communication. Feb. 24, 1995. 

19 Kevin Power, "Fate of Federal DSS in Doubt,” Government Computer News, Mar. 6, 1995. The President’s budget does provide $100 
million to implement the digital wiretap legislation enacted at the close of the 103d Congress. See U.S. Congress, Office of Technology Assess¬ 
ment, Electronic Surveillance in Advanced Telecommunications Networks, Background Paper, forthcoming, spring 1995. 

20 “Memorandum of Agreement Between the Advanced Research Projects Agency, the Defense Information Systems Agency, and the Na¬ 
tional Security Agency Concerning the Information Systems Security Research Joint Technology Office,” Mar. 3,1995 (effective Apr. 2,1995). 
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I Private Sector Developments 

At the end of January 1995, AT&T Coip. and 
VLSI Technology, Inc., announced plans to devel¬ 
op an encryption microchip that would rival the 
Clipper and Capstone chips. The AT&T/VLSI 
chip will have the stronger, triple-DES imple¬ 
mentation of the Data Encryption Standard algo¬ 
rithm. 21 It is intended for use in a variety of 
consumer devices, including cellular telephones, 
television decoder boxes for video-on-demand 
services, and personal computers. 22 The AT&T/ 
VLSI chips do not include key escrowing. Under 
current export regulations, they would be subject 
to State Department export controls. 

Industry observers consider this development 
especially significant as an indicator of the lack of 
market support for Clipper and Capstone chips be¬ 
cause AT&T manufactures a commercial product 
using Clipper chips (the AT&T Surity Telephone 
Device) and VLSI is the NS A contractor making 
the chips that Mykotronx programs (e.g., with the 
Skipjack algorithm and keys) to become Clipper 
and Capstone chips. 

The international banking and financial commu¬ 
nities have long used encryption and authentica¬ 
tion methods based on the DES. These have a 
large installed base of DES technology; a transi¬ 
tion to an incompatible (non-DES-based) new 
technology would be lengthy. The Accredited 
Standards Committee (ASC X9), which sets data 
security standards for the U.S. banking and finan¬ 


cial services industries, has announced that it will 
develop new encryption standards based on triple 
DES. ASC X9 will designate a subcommittee to 
develop technical standards for triple-DES ap¬ 
plications. 23 

RSA Data Security, Inc., recently announced 
another symmetric encryption algorithm, called 
RC5. 24 According to the company, RC5 is faster 
than the DES algorithm, is suitable for hardware 
or software implementation, and has a range of 
user-selected security levels. Users can select key 
lengths ranging up to 2,040 bits, depending on the 
levels of security and speed needed. The RSA dig¬ 
ital signature system (see box 2-2), from the same 
company, is a leading commercial rival to the Dig¬ 
ital Signature Standard. RSA-based technology is 
also part of a new, proposed industry standard for 
protecting business transactions on the Internet. 25 

Another private sector standards group, the 
IEEE PI363 working group on public-key cryp¬ 
tography, is developing a voluntary standard for 
“RSA, Diffie-Hellman, and Related Public-Key 
Cryptography” (see figure 2-5). The group held a 
public meeting in Oakland, California, on May 
10, 1995, to review a draft standard. 26 

Several companies and individuals have pro¬ 
posed alternative approaches to key-escrow 
encryption. 27 According to a “taxonomy” by Dor¬ 
othy Denning and Dennis Branstad, there are 
some 20 different alternatives, including: 


21 In “triple DES,” the DES algorithm is used sequentially with three different keys, to encrypt, decrypt, then re-encrypt. Triple encryption 
with the DES offers more security than having a secret key that is twice as long as the 56-bit key specified in the FIPS. There is, however, no FIPS 
specifying triple DES. 

22 Jared Sandberg and Don Clark, “AT&T, VLSI Technology To Develop Microchips That Offer Data Security,” The Wall Street Journal, 
Jan. 31, 1995; see also Brad Bass, op. cit., footnote 19. 

23 CIPHER (Newsletter of the IEEE Computer Society’s TC on Security and Privacy), Electronic Issue No. 4, Carl Landwehr (ed), Mar. 10, 
1995, available from (http://www.itd.nrl.navy.mil/ITD/5540/ieee/cipher/cipher-archive.html). 

24 Ronald L. Rivest, “The RC5 Encryption Algorithm,” Dr. Dobb’s Journal, January 1995, pp. 146, 148. 

25 Peter H. Lewis, “Accord Is Reached on a Common Security System for the Internet,” The New York Times, Apr. 11, 1995, p. D5. The 
proposed standard will be used to safeguard World Wide Web services. 

26 Ibid. Draft sections are available via anonymous ftp to rsa.com in the “pub/p 1363” directory. The working group’s electronic mailing list 
is <pl363@rsa.com>; to join, send e-mail to <pl363-request@rsa.com>. 

27 See Elizabeth Corcoran, “Three Ways To Catch a Code,” Washington Post, Mar. 16, 1995, pp. Bl, B12. The article also discusses the 
Hewlett-Packard’s proposed “national flag card” approach to government-approved encryption. 
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■ AT&T CryptoBackup, 

■ Bankers Trust International Corporate Key 
Escrow, 

■ Bell Atlantic Key Escrow, 

■ Fortress KISS, 

■ Micali Fair Cryptosystems, 

■ TECSEC VEIL, 

■ TIS Commercial Software Key Escrow 
System, 

■ and 

■ TIS Software Key Escrow System. 28 

Variously, these use public (i.e., published, un¬ 
classified) encryption algorithms, thus potentially 
allowing implementation in software as well as 
hardware. They use commercial or private key-es¬ 
crow systems, with data recovery services that can 
be made available to individuals and organiza¬ 
tions, as well as to law enforcement (with proper 
authorization). A brief description of two of the 
commercial approaches follows, based on in¬ 
formation provided by Trusted Information Sys¬ 
tems (TIS) and Bankers Trust. The Bankers Trust 
system is hardware based; the TIS system is soft- 
ware-based. 

Bankers Trust has proposed its system to the 
U.S. government and business community. Ac¬ 
cording to Bankers Trust, its international private 
key-escrow system ensures privacy and security, 
while preserving law enforcement and national se¬ 
curity capabilities. Bankers Trust believes there is 
a need for escrowed keys in business applications, 
so that encrypted information can be recovered 
when a key has been lost or is otherwise unavail¬ 
able. The Bankers Trust system supports different 
encryption methods, thus accommodating differ¬ 
ent national policies (e.g., regarding export, im¬ 
port, or use controls). The Bankers Trust system 


uses a hardware device to encrypt information 
stored in and transmitted through global infor¬ 
mation infrastructures, including voice, fax, 
store-and-forward messaging, and data-storage- 
and-retrieval systems. Bankers Trust believes that 
the requirement of a device will be consistent with 
the rapidly emerging use of smart cards for net¬ 
work financial transactions, together with the 
need to secure the global information infrastruc¬ 
ture against potential abuse. 29 

Under Bankers Trust’s system, the owner of the 
encryption device selects an encryption algorithm 
and escrows the key or fragments of the key with 
one or more trusted entities (escrow agents). 
These could be a commercial company. The sys¬ 
tem allows owners to freely change algorithms, 
keys, and agents at any time; owners might make 
these changes as part of a standard security policy 
or as an added security measure after any sus¬ 
pected problem. Bankers Trust’s system enables 
owners to access their key(s) to decrypt encrypted 
information when necessary. It also permits law 
enforcement, with proper legal authorization, to 
obtain keys to decrypt information. Additionally, 
it contains extensive audit and other procedures to 
ensure the integrity of the system. 30 

The government is looking at various alternative 
approaches to key-escrow encryption. At this 
writing, the commercial escrowing alternative 
proposed by Trusted Information Systems, Inc., is 
undergoing internal government review to deter¬ 
mine whether such an approach may be feasible to 
meet national security and law enforcement objec¬ 
tives. 31 The TIS approach is software rather than 
hardware-based. 32 Like the Bankers Trust system, 
but in contrast to the EES/Capstone approach to 
escrowing, it would also permit the rightful “key 


28 See Dorothy E. Denning and Dennis Branstad, “A Taxonomy for Key Escrow Encryption,” forthcoming, obtained from the author (den- 
ning@cs.georgetown.edu). 

29 Nanette DiTosto, Bankers Trust, personal communication, Apr. 10, 1995. 

30 Ibid. 

31 F. Lynn McNulty, Associate Director for Computer Security, NIST, personal communications, Feb. 24, 1995 and Mar. 21, 1995. 

32 Stephen T. Walker, et al., “Commercial Key Escrow: Something for Everyone, Now and for the Future,” Jan. 3,1995, Trusted Information 
Systems, Inc., TIS Report No. 541. 
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owners”—not just law enforcement agencies—to 
recover the contents of encrypted messages or 
files, if the keys became unavailable due to acci¬ 
dent, malfeasance, error, or so forth. 

In the TIS scheme, a user would register his or 
her escrowed-encryption computer program with 
a commercial, government, or corporate data re¬ 
covery center. The interactive registration process 
would provide the user’s computer program with 
information to be used in creating the “data recov¬ 
ery field” (analogous to the LEAF in the EES 
method—see box 2-3) that would be appended to 
all encrypted communications (or files). Any en¬ 
cryption algorithm could be used but the software 
implementation cannot protect the “secrecy” of a 
classified algorithm. According to TIS, its pro¬ 
posal relies on “binding” a software key-escrow 
system to the chosen encryption algorithm. Imple¬ 
menting this type of software “binding” is diffi¬ 
cult, but if done properly, it would prevent 
someone from separating the computer program’s 
encryption functions from the key-escrowing 
functions and would prevent use of the program 
for encryption using nonescrowed keys. The 
“binding” features of the TIS proposal are in¬ 
tended to prevent use of the encryption function if 
key escrowing is disabled, or “spoofing” the sys¬ 
tem by creating spurious data recovery fields. 33 

UPDATE ON BUSINESS PERSPECTIVES 

Representatives of major U.S. computer and soft¬ 
ware companies have reaffirmed the importance 
of security and privacy protections in the develop¬ 
ing global information infrastructure (GII). Ac¬ 
cording to the Computer Systems Policy Project 
(CSPP): 

The GII will not flourish without effective se¬ 
curity mechanisms to protect commercial trans¬ 
actions. Consumers and providers of products 
and services, particularly those involving health 


care and international commerce, will not use 
GII applications unless they are confident that 
electronic communications and transactions 
will be confidential, that the origin of messages 
can be verified, that personal privacy can be pro¬ 
tected, and that security mechanisms will not 
impede the transnational flow of electronic 
data . 34 

But there are strong and serious business concerns 
that government interests, especially in the stan¬ 
dards arena, could stifle commercial development 
and use of networks in the international arena: 

Governments have a critical interest in com¬ 
mercial security mechanisms that are consistent 
with their own national security needs. As a re¬ 
sult, they must participate in private sector ef¬ 
forts to develop and adopt security standards. 
However, government needs should not be used 
as reasons to replace or overwhelm the private 
sector standards processes. 

To meet the security goals for the GII (as well 
as privacy goals supported by security solutions), 
the CSPP recommended that: 

■ All participating countries must adopt stan¬ 
dards to support mechanisms that are accept¬ 
able to the private sector and suitable to 
commercial transactions. These standards 
must also ensure privacy and authentication. 
This may require nations to adopt commer¬ 
cial security solutions that are different and 
separate from solutions for national security 
and diplomatic purposes. 

■ The U.S. government must cooperate with in¬ 
dustry to resolve U.S. policy concerns that 
have blocked acceptance of international en¬ 
cryption mechanisms necessary for commer¬ 
cial transactions. 

■ The private sector and government should 
convene a joint international conference to 
address the need for security mechanisms to 
support commercial applications and to de- 


33 Steve Lipner, Trusted Information Systems, Inc., personal communication. Jan. 9, 1995. According to Lipner, the National Security 
Agency introduced the term binding to the lexicon, to refer to this feature. 

34 Computer Systems Policy Project, Perspectives on the Global Information Infrastructure , February 1995, p. 9. 
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velop a strategy for implementing acceptable 
security solutions . 35 

In June 1994, the Association for Computing 
Machinery (ACM) issued a report on the policy is¬ 
sues raised by introduction of the EES. The ACM 
report, prepared by a panel drawn from govern¬ 
ment, the computer industry, and the legal and 
academic communities, discussed the history and 
technology of cryptography and the value and im¬ 
portance of privacy, concluding with identifica¬ 
tion of key questions that need to be considered in 
reaching conclusions regarding: 

What cryptography policy best accommo¬ 
dates our national needs for secure communica¬ 
tions and privacy, industry success, effective 
law enforcement, and national security ? 36 

The U.S. Public Policy Committee of the ACM 
(USACM) issued a companion set of recommen¬ 
dations, focusing on the need for: 

■ open forums for cryptography policy devel¬ 
opment, in which government, industry, and 
the public could participate; 

■ encryption standards that do not place U.S. 
manufacturers at a disadvantage in the global 
marketplace and do not adversely affect tech¬ 
nological development within the United 
States; 

■ changes in FIPS development, such as plac¬ 
ing the process under the Administrative Pro¬ 
cedures Act; 

■ withdrawal of the Clipper chip proposal by 
the Clinton Administration and the begin¬ 
ning of an open and public review of encryp¬ 
tion policy; and 

■ development of technologies and institution¬ 
al practices that will provide real privacy for 
future users of the National Information In¬ 
frastructure (Nil ). 37 


Also in 1994, the International Chamber of 
Commerce (ICC) issued its “ICC Position Paper 
on International Encryption Policy.” ICC noted 
the growing importance of cryptography in secur¬ 
ing business information and transactions on an 
international basis and, therefore, the significance 
of restrictions and controls on encryption methods 
as “artificial obstacles” to trade. ICC urged gov¬ 
ernments “not to adopt a restrictive approach 
which would place a particularly onerous burden 
on business and society as a whole.” 38 ICC’s posi¬ 
tion paper called on governments to: 1) remove 
unnecessary export and import controls, usage re¬ 
strictions, restrictive licensing arrangements and 
the like on encryption methods used in commer¬ 
cial applications; 2) enable network interoperabil¬ 
ity by encouraging global standardization; 3) 
maximize users’ freedom of choice; and 4) work 
together with industry to resolve banters by joint¬ 
ly developing a comprehensive international 
policy on encryption. ICC recommended that 
global encryption policy be based on broad prin¬ 
ciples: 

■ Different encryption methods will be needed 
to fulfill a variety of user needs. Users should 
be free to use and implement the already ex¬ 
isting framework of generally available and 
generally accepted encryption methods and 
to choose keys and key management without 
restrictions. Cryptographic algorithms and 
key-management schemes must be open to 
public scrutiny for the commercial sector to 
gain the necessary level of confidence in 
them. 

■ Commercial users, vendors, and govern¬ 
ments should work together in an open in¬ 
ternational forum in preparing and approving 
global standards. 


Ibid., pp. 9-10. 

36 Susan Landau et al.. “Codes. Keys, and Conflicts: Issues in U.S. Crypto Policy," Association for Computing Machinery, Inc., June 1994. 

37 USACM, June 1994. 

38 International Chamber of Commerce, ICC Position Paper on International Encryption Policy (Paris: ICC, 1994). pp. 2,3. See also United 
States Council for International Business, “Private Sector Leadership: Policy Foundations for a National Information Infrastructure,” New 
York, NY, July 1994, p 5. 
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■ Both hardware and software implementations 
of encryption methods should be allowed. 
Vendors and users should be free to make 
technical and economic choices about modes 
of implementation and operation. 

■ Owners, providers, and users of encryption 
methods should agree on the responsibility, 
accountability, and liability for such 
methods. 

■ With the exception of encryption methods 
specifically developed for military or diplo¬ 
matic uses, encryption methods should not be 
subject to export or import controls, usage re¬ 
strictions, restrictive licensing arrangements, 
or other restrictions. 39 

The United States Council for International 
Business (USCIB) subsequently issued position 
papers on “Business Requirements for Encryp¬ 
tion” 40 and “Liability Issues and the U.S. Admin¬ 
istration’s Encryption Initiatives.” 41 The USCIB 
favored breaking down the “artificial barriers” to 
U.S. companies’ competitiveness and ability to 
implement powerful security imposed by overly 
restrictive export controls. The Council called for 
international agreement on realistic encryption re¬ 
quirements, including free choice of encryption 
algorithms and key management methods, public 
scrutiny of proposed standard algorithms, free ex¬ 
port/import of accepted standards, flexibility in 
implementation (hardware or software), and li¬ 
ability requirements for escrow agents if escrow¬ 
ing is used: 

Business recommends the removal of un¬ 
founded export controls on commercial encryp¬ 
tion. In the absence of relief from export 
controls, business recommends that the follow¬ 
ing steps be undertaken in order to achieve an 
encryption policy that is internationally accept¬ 
able: 


(a) the Administration endorse the require¬ 
ments outlined in this paper 

(b) the Administration enter into bilateral and 
multilateral discussions with other nations 
to achieve the widespread adoption of these 
requirements. 

If key escrowing is to be used, the USCIB pro¬ 
posed that: 

■ a government not be the sole holder of the en¬ 
tire key except at the discretion of the user; 

■ the key escrow agent make keys available to 
lawfully authorized entities when presented 
with proper, written legal authorizations (in¬ 
cluding international cooperation when the 
key is requested by a foreign government); 

■ the process for obtaining and using keys for 
wiretapping purposes must be auditable; 

■ keys obtained from escrowing agents by law 
enforcement must be used only for a speci¬ 
fied, limited time frame; and 

■ the owner of the key must (also) be able to ob¬ 
tain the keys from the escrow agent. 43 

The USCIB has also identified a number of 
distinctive business concerns with respect to the 
U.S. government’s position on encryption and 
liability: 

■ uncertainty regarding whether the Clinton 
Administration might authorize strict gov¬ 
ernment liability for misappropriation of 
keys, including adoption of tamperproof 
measures to account for every escrowed unit 
key and family key (see box 2-3); 

■ the degree of care underlying design of Skip¬ 
jack, EES, and Capstone (given the govern¬ 
ment’s still-unresolved degree, if any, of 
liability); 

■ the confusion concerning whether the gov¬ 
ernment intends to disclaim all liability in 
connection with the EES and Capstone initia- 


Ibid., pp. 3-4. 

40 United States Council for International Business, “Business Requirements for Encryption," New York, NY, Oct. 10, 1994. 

41 United States Council for International Business, “Liability Issues and the U.S. Administration’s Encryption Initiatives,” New York, NY, 
Nov. 2, 1994. 

42 USCIB, op. cit., footnote 40, pp. 3-4. 
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tives, and the extent to which family keys, 
unit keys, and law enforcement decryption 
devices will be adequately secured; and 
■ uncertainties regarding the liability of non¬ 
governmental parties (e.g., chip manufactur¬ 
ers, vendors, and their employees) for 
misconduct or negligence. 43 

These types of concerns have remained unre¬ 
solved (see related discussion and options pres¬ 
ented in the 1994 OTA report, pp. 16-18 and 
171-182). 

Liability issues are important to the develop¬ 
ment of electronic commerce and the underpin¬ 
ning institutional infrastructures, including (but 
not limited to) escrow agents for key-escrowed 
encryption systems and certificate authorities for 
public-key infrastructures. Widespread use of cer¬ 
tificate-based public-key infrastructures will re¬ 
quire resolution and harmonization of liability 
requirements for trusted entities, whether these be 
federal certificate authorities, private certificate 
(or “certification”) authorities, escrow agents, 
banks, clearinghouses, value-added networks, or 
other entities. 44 

There is increasing momentum toward frame¬ 
works within which to resolve legal issues per¬ 
taining to digital signatures and to liability. For 
example: 

■ The Science and Technology Section of the 
American Bar Association’s Information Secu¬ 


rity Committee is drafting “Global Digital Sig¬ 
nature Guidelines” and model digital-signature 
legislation. 

■ With participation by the International Cham¬ 
ber of Commerce and the U.S. State Depart¬ 
ment, the United Nations Commission on 
International Trade Law has completed a Mod¬ 
el Law on electronic data interchange (EDI). 

■ Utah has just enacted digital signature legisla¬ 
tion. 45 

The Utah Digital Signature Act 46 is intended to 
provide a reliable means for signing computer- 
based documents and legal recognition of digital 
signatures using “strong authentication tech¬ 
niques” based on asymmetric cryptography. To 
assure a minimum level of reliability in digital 
signatures, the Utah statute provides for the li¬ 
censing and regulation of certification authorities 
by a “Digital Signature Agency” (e.g., the Divi¬ 
sion of Corporations and Commercial Code of the 
Utah Department of Commerce). The act, first 
drafted as a proposed model law, provides that the 
private key is the property of the subscriber who 
rightfully holds it (and who has a duty to keep it 
confidential); thus, tort or criminal actions are 
possible for theft or misuse. It is technology-inde¬ 
pendent; that is, it does not mandate use of a spe¬ 
cific signature technique. 47 The management of 
the system described in the Utah statute can easily 


43 USCIB, op. cit., footnote 41, pp. 2-6. 

44 See footnote 13 for discussion of liability exposure, legal considerations, tort and contract remedies, government consent to be liable, and 
recommendations and approaches to mitigate liability. 

45 Information on the American Bar Association and United Nations activities provided by Michael Baum, Principal, Independent Monitor¬ 
ing, personal communication, Mar. 19,1995. See also Michael S. Baum, Federal Certification Authority Liability and Policy: Law and Policy of 
Certificate-Based Public Key and Digital Signatures, NIST-GCR-94-654, NTIS Doc. No. PB94-191-202 (Springfield, VA: National Technical 
Information Service, 1994). 

46 Utah Digital Signature Legislative Facilitation Committee, “Utah Digital Signature Legislation,” Dec. 21,1994. The Utah Digital Signa¬ 
ture Act was signed into law on March 10, 1995, as section 46-3-101 et seq., Utah Code Annotated. (Prof. Lee Hollaar, University of Utah, 
personal communication. Mar. 22, 1995.) 

47 Utah Digital Signature Act, ibid. The model legislation was endorsed by the American Bar Association, Information Security Committee 
of the Science and Technology Section, EDI/Information Technology Division; Prof. Lee Hollaar, University of Utah; Salt Lake Legal Defend¬ 
ers Assoc.; Statewide Association of Public Attorneys; Utah Attorney General’s Office; Utah Dept, of Corrections; Utah Information Technolo¬ 
gy Commission; Utah Judicial Council; and Utah State Tax Commission. 
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be privatized and globalized. 48 The information at 
the Digital Signature Agency can be as little as the 
authorization of one or more private sector certifi¬ 
cate authorities; a certificate authority can operate 
in many states, having authorizations for each. 49 

UPDATE ON PRIVACY LEGISLATION 

In the 104th Congress, bills have been introduced 
to address the privacy-related issues of search and 
seizure, access to personal records, content of 
electronic information, drug testing, and im¬ 
migration and social security card fraud problems. 
In addition, Representative Cardiss Collins has re¬ 
introduced legislation (H.R. 184) to establish a 
Privacy Protection Commission. 

The “Individual Privacy Protection Act of 1995” 
(H.R. 184) is identical to legislation Representa¬ 
tive Collins introduced in the 103rd Congress 
(H.R. 135). Both bills are similar to legislation 
introduced in the 103rd Congress by Senator Paul 
Simon (S. 1735). The establishment of a Privacy 
Protection Commission was endorsed by the Vice 
President’s National Performance Review and en¬ 
couraged in a 1993 statement by Sally Katzen, the 
Administrator of the Office of Information and 
Regulatory Affairs in the Office of Management 
and Budget. 50 H.R. 184 would establish a five- 
member Privacy Protection Commission charged 
with ensuring the privacy rights of U.S. citizens, 
providing advisory guidance on matters related to 
electronic data storage, and promoting and en¬ 
couraging the adoption of fair information prac¬ 
tices and the principle of collection limitation. 

Immigration concerns and worker eligibility are 
prompting reexamination of social security card 
fraud and discussion over a national identification 
database. At least eight bills have been introduced 


in the 104th Congress to develop tamper-proof or 
counterfeit-resistant social security cards (H.R. 
560, H.R. 570, H.R. 756, H.R. 785) and to pro¬ 
mote research toward a national identification da¬ 
tabase (H.R. 502, H.R. 195, S. 456, S. 269). 

Four bills have been introduced modifying 
search and seizure limitations: H.R. 3, H.R. 666, 
S. 3, and S. 54. The “Exclusionary Rule Reform 
Act of 1995” (H.R. 666 and companion S. 54), 
which revises the limitations on evidence found 
during a search, passed the House on February 10, 
1995. Similar provisions have been included in 
crime legislation introduced in both Houses, S. 3 
and H.R. 3. The Senate Committee on the Judicia¬ 
ry has held a healing on Title V of S. 3, the provi¬ 
sions reforming the exclusionary rule. 

Also this session, legislation has been intro¬ 
duced increasing privacy protection by restricting 
the use or sale of lists collected by communication 
carriers (H.R. 411) and the U.S. Postal Service 
(H.R. 434), defining personal medical privacy 
rights (H.R. 435, S. 7), detailing acceptable usage 
of credit report information (H.R. 561), and man¬ 
dating procedures for determining the reliability 
of drug testing (H.R. 153). These bills establish 
guidelines in specific areas, but do not attempt to 
address the overall challenges facing privacy 
rights in an electronic age. 

The “Family Privacy Bill” (H.R. 1271) passed 
the House on April 4, 1995. H.R. 1271, 
introduced by Representative Steve Horn on 
March 21,1995, is intended to provide parents the 
right to supervise and choose their children’s par¬ 
ticipation in any federally funded survey or ques¬ 
tionnaire that involves intrusive questioning on 
sensitive issues. 51 Some have raised concerns 
about the bill on the grounds that it might danger- 


48 The Utah act envisions use of signatures based on standards similar to or including the ANSI X.9.30 or ITU X.509 standards (ibid.). 

49 Prof. Lee Hollaar, University of Utah, personal communication. Mar. 22, 1995. 

50 Statement by Sally Katzen, Administrator, Office of Information and Regulatory Affairs, OMB and Chair, Information Policy Commit¬ 
tee, Information Infrastructure Task Force, Nov. 18th, 1993 (Congressional Record , p. S.5131). 

51 Representative Scott Mclnnis, Congressional Record , Apr. 4, 1995, p. H4126. 
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ously limit local police authority to question mi¬ 
nors and threaten investigations of child abuse, or 
hinder doctors in obtaining timely patient in¬ 
formation on children. 52 

In addition, the Office of Management and 
Budget recently published notice of “Draft Prin¬ 
ciples for Providing and using Personal Informa¬ 
tion and Commentary. 52 ” These were developed 
by the Information Infrastructure Task Force’s 
Working Group on Privacy and are intended to up¬ 
date and revise the Code of Fair Information Prac¬ 
tices that was developed in the early 1970s and 
used in development of the Privacy Act of 1974. 

UPDATE ON INFORMATION-SECURITY 
POLICY INITIATIVES AND LEGISLATION 

The Defense Department’s “Information Warfare” 
activities address the opportunities and vulnera¬ 
bilities inherent in its (and the country’s) increas¬ 
ing reliance on information and information 
systems. There are a variety of Information War¬ 
fare activities ongoing in Department services and 
agencies, the Office of the Secretary of Defense, 
and elsewhere. 54 The Department’s Defensive 
Information Warfare program goals focus on tech¬ 
nology development to counter vulnerabilities 
stemming from its growing dependence on 
information systems and the commercial informa¬ 
tion infrastructure (e.g., the public-switched net¬ 
work and the Internet). The Information Systems 
Security Research Joint Technology Office estab¬ 
lished by ARPA, DIS A, and NS A (see above) will 
pursue research and development pursuant to 
these goals. 

The increasing prominence of Information War¬ 
fare issues has contributed to an increasing mo¬ 


mentum for consolidating information-security 
authorities government-wide, thereby increasing 
the role of the defense and intelligence agencies 
for unclassified information security overall: 

Protection of U.S. information systems is 
also clouded by legal restrictions put forth, for 
example, in the Computer Security Act of 1987. 

Of concern to the Task Force is the fact that 
IW [Information Warfare] technologies and ca¬ 
pabilities are largely being developed in an open 
commercial market and are outside of direct 
Government control. 55 

Such a consolidation and/or expansion would run 
counter to current statutory authorities and to the 
Office of Management and Budget the Office of 
Management and Budget (OMB’s) proposed new 
government-wide security and privacy policy- 
guidance (see below). 

I The Joint Security Commission 

In mid-1993, the Joint Security Commission was 
convened by the Secretary of Defense and the Di¬ 
rector of Central Intelligence to develop a “new 
approach to security that would assure the adequa¬ 
cy of protection within the contours of a security 
system that is simplified, more uniform, and more 
cost effective.” 56 The Joint Security Commis¬ 
sion’s report made recommendations across a 
comprehensive range of areas, including: 

■ classification management; 

■ threat assessments; 

■ personnel security and the clearance process; 

■ physical, technical, and procedural security; 

■ protection of advanced technologies; 

■ a joint investigative service; 

■ accounting for the costs of security; 


5 - Representative Cardiss Collins, Congressional Record , Apr. 4, 1995, p. H4126. 

53 Federal Register, Jan. 20, 1995. pp. 4362-4370. 

54 See, e.g. Office of the Under Secretary of Defense for Acquisition and Technology, “Report of the Defense Science Board Summer Study 
Task Force on Information Architecture for the Battlefield,” October 1994. 

55 Ibid., p. 52. 

56 Joint Security Commission, Redefining Security: A Report to the Secretary of Defense and Director of Central Intelligence, Feb. 28,1994 
(quote from letter of transmittal). See also U.S. Congress, House of Representatives, Permanent Select Committee on Intelligence, “Intelligence 
Authorization Act for Fiscal Year 1994,” Rept. 103-162, Part I, 103d Congress, 1st session, June 29, 1993, pp. 26-27. 
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■ security awareness, training, and education; 

■ information systems security ; and 

■ a security architecture for the future [empha¬ 
sis added]. 57 

The Joint Security Commission report’s sec¬ 
tions on information systems security 58 and a se¬ 
curity architecture for the future 59 are of special 
interest. In the context of its charter, the Commis¬ 
sion proposes a unified security policy structure 
and authority for classified and unclassified in¬ 
formation in the defense/intelligence communi¬ 
ty. 60 However, the report also recommends a more 
general centralization of information security 
along these lines government-wide; the executive 
summary highlights the conclusion that the secu¬ 
rity centralization within the defense/intelligence 
community described in the report should be ex¬ 
tended government-wide. 61 The report also rec¬ 
ommends “establishment of a national level 
security policy committee to provide structure and 
coherence to U.S. Government security policy, 
practices and procedures.” 62 

I The Security Policy Board 

On September 16, 1994, President Clinton signed 
Presidential Decision Directive 29 (PDD-29). 
PDD-29, “Security Policy Coordination,” estab¬ 
lished a new structure, under the direction of the 
National Security Council (NSC), for the coor¬ 
dination, formulation, evaluation, and oversight 
of U.S. security policy. 63 According to the de¬ 
scription of PDD-29 provided to OTA by NSC, 
the directive designates the former Joint Security 
Executive Committee established by the Secre¬ 


tary of Defense and the Director of Central Intelli¬ 
gence as the Security Policy Board. 

The Security Policy Board (SPB) subsumes the 
functions of a number of previous national securi¬ 
ty groups and committees. The SPB members in¬ 
clude the Director of Central Intelligence, Deputy 
Secretary of Defense, Vice Chairman of the Joint 
Chiefs of Staff, Deputy Secretary of State, Under 
Secretary of Energy, Deputy Secretary of Com¬ 
merce, and Deputy Attorney General; plus one 
Deputy Secretary from “another non-defense re¬ 
lated agency” selected on a rotating basis, and one 
representative each from OMB and NSC staff. 

The Security Policy Forum that had been estab¬ 
lished under the Joint Security Executive Com¬ 
mittee was retained under the SPB. The forum is 
composed of senior representatives from over two 
dozen defense, intelligence, and civilian agencies 
and departments; the forum chair is appointed by 
the SPB chair. The Security Policy Forum func¬ 
tions are to: consider security policy issues raised 
by its members or others, develop security policy 
initiatives and obtain comments for the SPB from 
departments and agencies, evaluate the effective¬ 
ness of security policies, monitor and guide the 
implementation of security policies to ensure co¬ 
herence and consistency, and oversee application 
of security policies to ensure they are equitable 
and consistent with national goals. 64 

PDD-29 also established a Security Policy Ad¬ 
visory Board of five members from industry. This 
independent, nongovernmental advisory board is 
intended to advise the President on implementa¬ 
tion of the policy principles guiding the “new” 


57 Joint Security Commission, ibid. 

58 Ibid., pp. 101-113. 

Ibid., pp. 127 et seq. 

60 Ibid., p. 105, first paragraph.; p. 110, recommendation; pp. 127-130. 

61 Ibid., p. viii, top. 

62 Ibid., p. 130. 

63 Although it is unclassified. PDD-29 has not been released. This discussion is based on a fact sheet provided to OTA by NSC; the fact sheet 
is said to be a “nearly verbatim text of the PDD," with the only differences being “minor grammatical ones." David S. Van Tassel (Director, 
Access Management, NSC), letter to Joan Winston (OTA) and enclosure, Feb. 16, 1995. 

64 Ibid, (fact sheet). 
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formulation, evaluation, and oversight of U.S. se¬ 
curity policy, and to provide the SPB and the intel¬ 
ligence community with a “public interest” 
perspective. The SPB is authorized to establish in¬ 
teragency working groups as necessary to cany 
out its functions and to ensure interagency input to 
and coordination of security policy, procedures, 
and practices, with staffs to support the SPB and 
any other groups or fora established pursuant to 
PDD-29. 

PDD-29 was not intended to change or amend 
existing authorities or responsibilities of the 
members of the SPB, as “contained in the Nation¬ 
al Security Act of 1947, other existing laws or 
Executive Orders.” 65 PDD-29 does not refer spe¬ 
cifically to government information security 
policy, procedures, and practices, or to unclassi¬ 
fied information security government-wide. Nev¬ 
ertheless, the proposed detailed implementation 
of the directive with respect to information securi¬ 
ty, as articulated in the Security Policy Board’s 
staff report, “Creating a New Order in U.S. Securi¬ 
ty Policy,” is a departure from the information se¬ 
curity structure set forth in the Computer Security 
Act of 1987. The SPB staff report appears to rec¬ 
ognize this mismatch between its proposal and 
statutory authorities for unclassified information 
security, noting the Computer Security Act under 
information-security “actions required” to imple¬ 
ment PDD-29. 66 

The SPB staff report’s proposed “new order” for 
information security builds on the Joint Security 
Commission’s analysis and recommendations to 
establish a “unifying body” government-wide. 67 
With respect to information security, the new SPB 
structure would involve organizing an Informa¬ 
tion Systems Security Committee (ISSC) charged 
with “coupling the development of policy for both 


the classified and the sensitive but unclassified 
communities.” The SPB staff report generally 
notes that: 

Realignment into this new structure will re¬ 
quire a transition effort that will include the nec¬ 
essary coordination to effect changes to several 
executive and legislative edicts. 

. . . An endorsement of this proposed reorga¬ 
nization will include authorization for the Di¬ 
rector, Board Staff to proceed with the 
establishment of a transition team and coordi¬ 
nate all activities necessary to effect the U.S. 
Government’s conversion to this new struc¬ 
ture. 68 

As motivation for the changes, the SPB staff re¬ 
port notes that: 

Nowhere in the proposed new order does the 
goal to create cohesive, cost-effective, and op¬ 
erationally effective security policy encounter a 
greater challenge than in the area of protecting 
information systems and networks. The national 
architecture under development will provide 
vast amounts of information to all consumers 
rapidly and for a reasonable price. The ability to 
link and communicate with a wide variety of 
networks will not only be a key to productivity 
but will also be an “Achilles heel.” Some of this 
nation’s most significant vulnerabilities lie 
within the sensitive but unclassified networks 
that perform the basic function that we all take 
for granted. The coupling of policy require¬ 
ments for sensitive but unclassified systems 
within those for classified systems dictates the 
need for a comprehensive structure to address 
these needs in a cohesive fashion. 69 

This “comprehensive structure” would be the new 
Information Systems Security Committee 
(ISSC), which would be: 


65 Ibid. 

66 U.S. Security Policy Board Staff, "Creating a New Order in U.S. Security Policy,” Nov. 21, 1994. p. 18. 

67 Ibid., p. 3. See Elizabeth Sikorovsky, "NSC Proposes To Shift Policy-Making Duties,” Federal Computer Week, Jan. 23.1995. pp. 1,45. 
See also Kevin Power, “Administration Floats New Information Security Policy,” Government Computer News, Jan. 23. 1995, p. 59. 

68 U.S. Security Policy Board Staff. op. cit., footnote 66, p. II III. 

69 Ibid., p. 15. 
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.. .based on the foundation of the current 
NSTISSC [National Security Telecommunica¬ 
tions and Information Systems Security Com¬ 
mittee, see appendix B] but will have 
responsibility for both the classified and the sen¬ 
sitive but unclassified world. 

The ISSC would be jointly chaired at the SES 
[Senior Executive Service] or General Officer 
level by DOD and OMB. This new body would 
consist of voting representatives from each of 
the agencies/departments currently represented 
on the NSTISSC and its two subcommittees, 
NIST and the civil agencies it represents, and 
other appropriate agencies/departments, such as 
DISA, which are currently not represented on 
the NSTISSC. This body would create working 
groups as needed to address topics of interest. 

The ISSC would eventually have authority 
over all classified and unclassified but sensitive 
systems, and would report to through the [Secu¬ 
rity Policy] Forum and Board to the NSC. Thus, 
policies would have the full force and authority 
of an NSC Directive, rather than the relatively 
“toothless” issuances currently emanating from 
the NSTISSC. NSA would continue to provide 
the secretariat to the new national INFOSEC 
[Information Security] structure, since the sec¬ 
retariat is a well-functioning, highly-efficient, 
and effective body. 

. . .A joint strategy would have to be devised 
for a smooth transition between the current and 
new structures, which would ensure that current 
momentum is maintained and continuity pre¬ 
served. In addition, a new definition must be de¬ 
veloped for “national security information, ” 
and it must be determined how such information 
relates to the unclassified arena from a national 
security standpoint [emphasis added]. Issues 
such as voting in such a potentially unwieldy or¬ 
ganization must also be resolved. 70 


At this writing, the extent to which the SPB 
information security proposals, ISSC, and the 
development of a new definition of “national se¬ 
curity information” have or have not been “en¬ 
dorsed” within the executive branch is unclear. 
Outside the executive branch, however, the pro¬ 
posals have been met with concern and dismay 
reminiscent of reactions to National Security De¬ 
cision Directive-145 (NSDD-145) a decade ago 
(see chapter 2 and appendix B). 71 Moreover, they 
run counter to the statutory agency authorities set 
forth in the 104th Congress in the Paperwork Re¬ 
duction Act of 1995 (see below), as well as those 
in the Computer Security Act of 1987. 

At its March 23-24, 1995 meeting, the Comput¬ 
er Systems Security and Privacy Board that was 
established by the Computer Security Act issued 
Resolution 95-3, recommending that the SPB 
await broader discussion of issues before proceed¬ 
ing with its plans “to control unclassified, but sen¬ 
sitive systems.” 

Concerns have also been expressed within the 
executive branch. The ISSC information-security 
structure that would increase the role of the de¬ 
fense and intelligence communities in govern¬ 
ment-wide unclassified information security runs 
counter to the Clinton Administration’s “basic as¬ 
sumptions” about free information flow and pub¬ 
lic accessibility as articulated in the 1993 revision 
of OMB Circular A-130, “Management of Federal 
Information Resources.” 72 

Moreover, some senior federal computer securi¬ 
ty managers have expressed concern about what 
they consider premature implementation of the 
SPB staff report’s proposed centralization of in- 
formation-security functions and responsibilities. 
In a January 11, 1995, letter to Sally Katzen, Ad¬ 
ministrator, Office of Information and Regulatory 


70 Ibid., pp. 17-18. See appendix C of this paper and OTA, op. cit., footnote 1, pp. 132-148 for discussion of NSDD-145, the intent of the 
Computer Security Act of 1987, and NSTISSC. 

71 See Neil Munro, “White House Security Panels Raise Hackles,” Washington Technology , Feb. 23, 1995, pp. 6,8. 

72 OMB Circular A-130—Revised, June 25, 1993, Transmittal Memorandum No. 1, sec. 7. 
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Affairs (released March 23, 1995), the Steering 
Committee of the Federal Computer Security Pro¬ 
gram Manager’s Forum 73 indicated “unanimous 
disagreement” with the Security Policy Board’s 
proposal and urged OMB to “take appropriate ac¬ 
tion to restrict implementation of the SPB report 
to only classified systems” for the following rea¬ 
sons: 

1. The establishment of a national security 
community dominated Information System 
Security Committee having jurisdiction for 
both classified and unclassified systems is 
contrary to the Computer Security Act. Fur¬ 
thermore, it is not consistent with the author¬ 
ity of PDD-29 which requires coordination 
of national security policy [emphasis add¬ 
ed], 

2. This initiative also undercuts a stated Ad¬ 
ministration goal for an “open government” 
in which the free flow of information is facil¬ 
itated by removing government restrictions 
and regulations. For example, the SPB docu¬ 
ment states that a priority project for the new 
committee will be to craft a broad new defi¬ 
nition for “national security related informa¬ 
tion.” This will be viewed by many as an 
attempt to impose new restrictions on access 
to government information. 

3. The SPB proposal may serve to increase 
concerns over the government’s intentions 
in the field of information security. We know 
from observing the public debate over 
NSDD-145 and the Clipper Chip that the pri¬ 
vate sector deeply mistrusts the intentions of 
the government to use information security 
policy as a lever to further goals and objec¬ 
tives viewed as contrary to the interests of 
the business community. Congress passed 
the Computer Security Act of 1987 in re¬ 
sponse to expressions of displeasure from 


the private sector regarding the unwelcome 
overtures by the national security communi¬ 
ty towards “assisting” the private sector un¬ 
der the auspices of national security. This 
was perceived as having a significant ad¬ 
verse impact upon personal privacy, com¬ 
petitiveness and potential trade markets. 

4. We believe that it is inappropriate for the na¬ 
tional security and intelligence communi¬ 
ties to participate in selecting security 
measures for unclassified systems at civilian 
agencies. Their expertise in protecting na¬ 
tional security systems is not readily trans¬ 
ferable to civil agency requirements. The 
primary focus of security in the classified 
arena is directed towards protecting the con¬ 
fidentiality of information with little con¬ 
cern for cost effectiveness. Unclassified 
systems, however, which constitute over 
90% of the government’s IT [information 
technology] assets, have significantly fewer 
requirements for confidentiality vis-a-vis 
the need for integrity and availability. In 
these times of diminishing resources, cost- 
effectiveness is of paramount concern in the 
unclassified arena. 74 

The letter concludes: 

The Steering Committee is most concerned 
that the report is being misrepresented as Ad¬ 
ministration policy. Indicative of this is that 
“transition teams” are being formed to imple¬ 
ment the report. 

Please consider these facts and take action to 
restrict the SPB report implementation to only 
classified systems. 75 

This type of restriction appears to have been incor¬ 
porated in the proposed revision to Appendix III 
of OMB Circular A-130 (see below). 


73 The Federal Computer Security Program Manager’s Forum is made up of senior computer security managers for civilian agencies, in- 
eluding the Departments of Commerce, Health and Human Services, Justice, and Transportation. The Jan. 11,1995, letter to Sally Katzen was 
signed by Lynn McNulty, Forum Chair (National Institute of Standards and Technology) and Sadie Pitcher, Forum Co-chair (Department of 
Commerce). Text of letter taken from the online EPIC Alert, vol. 2.05, Mar. 27, 1995. 

74 Ibid. 

75 Ibid. 
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In March and April 1995, OTA invited the Se¬ 
curity Policy Board staff to comment on draft 
OTA text discussing information-security central¬ 
ization, including the Joint Security Commission 
report, PDD-29, and the SPB staff report. OTA re¬ 
ceived SPB staff comments in early May 1995, as 
this background paper was in press. According to 
the Security Policy Board staff director, informa¬ 
tion systems security policy is a “work in progress 
in its early stages” for the SPB and the staff report 
was intended to be a “strawman” stalling point for 
discussion. Moreover, according to the SPB staff, 
“recognizing the sensitivity and complexity of In¬ 
formation Systems Security policy, the ISSC was 
not one of the committees which was established, 
nor was a transition team formed. 76 ” In order to 
provide as much information as possible for con¬ 
sideration of information security issues, includ¬ 
ing the SPB staff perspective, OTA has included 
the SPB staff comments in box 1-3 on page 30. 

I The Paperwork Reduction Act of 1995 

The Paperwork Reduction Act was reauthorized 
in the 104th Congress. The House and Senate ver¬ 
sions of the Paperwork Reduction Act of 1995 
(H.R. 830 and S.244) both left existing agency au¬ 
thorities under the Computer Security Act of 1987 
unchanged. 77 The Paperwork Reduction Act of 
1995 (Public Law 104-13) was reported on April 
3, 1995 78 and passed in both Houses on April 6, 
1995. 


Among its goals, the Paperwork Reduction Act 
of 1995 is intended to make federal agencies more 
responsible and publicly accountable for informa¬ 
tion management. With respect to safeguarding 
information, the act seeks to: 

.. .ensure that the creation, collection, main¬ 
tenance, use, dissemination, and disposition of 
information by or for the Federal Government is 
consistent with applicable laws, including laws 
relating to— 

(A) privacy and confidentiality, including sec¬ 
tion 552a of Title 5; 

(B) security of information, including the Com¬ 
puter Security Act of 1987 (Public Law 
100-235); and 

(C) access to information, including section 
552 of Title 5. 79 

With respect to privacy and security, the Paper¬ 
work Reduction Act of 1995 provides that the Di¬ 
rector of OMB shall: 

1. develop and oversee the implementation of 
policies, principles, standards, and guide¬ 
lines on privacy, confidentiality, security, 
disclosure, and sharing of information col¬ 
lected or maintained by or for agencies; 

2. oversee and coordinate compliance with 
sections 552 and 552a of title 5, the Comput¬ 
er Security Act of 1987 (40 U.S.C. 759 note), 
and related information management laws; 
and 

3. require Federal agencies, consistent with the 
Computer Security Act of 1987 (40 U.S.C. 


76 Peter D. Saderholra (Director, Security Policy Board Staff), memorandum for Joan D. Winston and Miles Ewing (OTA), SPB 095-95, 
May 4, 1995. 

77 Senator William V. Roth, Jr., Congressional Record, Mar. 6, 1995. p. S3512. 

78 U.S. Congress, House of Representatives, “Paperwork Reduction Act of 1995—Conference Report to Accompany S.244,” H. Rpt. 
104-99, Apr. 3.1995. As the “Joint Explanatory Statement of the Committee of the Conference” (ibid., pp. 27-39) notes, the 1995 act retains the 
legislative history of the Paperwork Reduction Act of 1980. Furthermore, the definition of “information technology” in the 1995 act is intended 
to preserve the exemption for military and intelligence information technology that is found in current statutory definitions of “automatic data 
processing." The 1995 act accomplishes this by referring to the so-called Warner Amendment exemptions to the Brooks Act of 1965 and. thus, 
to section 111 of the Federal Property and Administrative Services Act (ibid., pp. 28-29). See also discussion of the Warner Amendment exemp¬ 
tions from the FIPS and the Computer Security Act in appendix B of this paper. 

79 Ibid., section 3501(8). The act amends chapter 35 of title 44 U.S.C. 
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59 note), to identify and afford security 
protections commensurate with the risk and 
magnitude of the harm resulting from the 
loss, misuse, or unauthorized access to or 
modification of information collected or 
maintained by or on behalf of an agency. 80 

The latter requirement for cost-effective security 
implementation and standards is tied to the roles 
of the Director of NIST and the Administrator of 
General Services in helping the OMB to: 

(A) develop and oversee the implementation of 
polices, principles, standards, and guide¬ 
lines for information technology functions 
and activities of the Federal Government, 
including periodic evaluations of major in¬ 
formation systems; and 

(B) oversee the development and implementa¬ 
tion of standards under section 111(d) of the 
Federal Property and Administrative Ser¬ 
vices Act of 1949 (40 U.S.C. 759(d)). 81 

Federal agency heads are responsible for ensuring 
that their agencies shall: 

1. implement and enforce applicable policies, 
procedures, standards, and guidelines on 
privacy, confidentiality, security, disclosure, 
and sharing of information collected or 
maintained by or for the agency; 

2. assume responsibility and accountability for 
compliance with and coordinated manage¬ 
ment of sections 552 and 552a of title 5, the 
Computer Security Act of 1987 (40 U.S.C. 
759 note), and related information manage¬ 
ment laws; and 

3. consistent with the Computer Security Act 
of 1987 (40 U.S.C. 59 note), identify and af¬ 
ford security protections commensurate 
with the risk and magnitude of the harm 
resulting from the loss, misuse, or unau¬ 
thorized access to or modification of in¬ 


formation collected or maintained by or on 
behalf of an agency. 82 

I Proposed Revision of 
OMB Circular A-130 Appendix III 

At this writing, OMB has just completed the pro¬ 
posed revision of Appendix III. The proposed re¬ 
vision is intended to lead to improved federal 
information-security practices and to make fulfill¬ 
ment of Computer Security Act and Privacy Act 
requirements more effective generally, as well as 
with respect to data sharing and secondary uses. 
As indicated above, the Paperwork Reduction Act 
of 1995 has affirmed OMB's government-wide 
authority for information security and privacy. 

The new, proposed revision of Appendix III 
(“Security of Federal Automated Information”) 
will be key to assessing the prospect for improved 
federal information-security practices. The pro¬ 
posed revision was posted for public comment on 
March 29, 1995. According to OMB, the pro¬ 
posed new government-wide guidance: 

... is intended to guide agencies in securing 
information as they increasingly rely on an open 
and interconnected National Information Infra¬ 
structure. It stresses management controls such 
as individual responsibility, awareness and 
training, and accountability, rather than techni¬ 
cal controls. 

. . . The proposal would also better integrate 
security into program and mission goals, reduce 
the need for centralized reporting of paper secu¬ 
rity plans, emphasize the management of risk 
rather than its measurement, and revise govern¬ 
ment-wide security responsibilities to be consis¬ 
tent with the Computer Security Act. 83 

According to OMB, the proposed new security 
guidance reflects the significant differences in ca- 


80 Ibid., section 3504(g). The OMB Director delegates authority to administer these functions to the Administrator of OMB's Office of In- 
formation and Regulatory Affairs. 

81 Ibid., section 3504(h)(1). See also “Joint Explanatory Statement of the Committee of the Conference,” ibid., pp. 27-29. 

82 Ibid., section 3506(g). 

83 Office of Management and Budget, “Security of Federal Automated Information,” Proposed Revision of OMB Circular No. A-130 Ap¬ 
pendix III (transmittal memorandum), available via World Wide Web at http://csrc.ncsl.nist.gov/secplcy as <al30app3.txt>. 
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pabilities, risks, and vulnerabilities of the present 
computing environment, as opposed to the rela¬ 
tively closed, centralized processing environment 
of the past. Today’s processing environment is 
characterized by open, widely distributed in- 
formation-processing systems that are intercon¬ 
nected with other systems within and outside 
government and by an increasing dependence of 
federal agency operations on these systems. 
OMB’s “federal information technology world” 
encompasses over 2 million individual worksta¬ 
tions (e.g., PCs), but only some 25,000 medium 
and large computers. 84 Accordingly, a major fo¬ 
cus of OMB’s new guidance is on end users and 
decentralized information-processing systems— 
and the information-processing applications they 
use and support. 

According to OMB, the proposed revision of 
Appendix III stresses management controls (such 
as individual responsibility, awareness, and train¬ 
ing) and accountability, rather than technical con¬ 
trols. OMB also considers that the proposed 
security appendix would better integrate security 
into agencies’ program and mission goals, reduce 
the need for centralized reporting of paper security 
plans, emphasize the management of risk rather 
than its measurement, and revise government¬ 
wide security responsibilities to be consistent 
with the Computer Security Act. 85 

OMB’s proposed new security appendix: 

. . .proposes to re-orient the Federal comput¬ 
er security program to better respond to a rapidly 
changing technological environment. It estab¬ 
lishes government-wide responsibilities for 
Federal computer security and requires Federal 
agencies to adopt a minimum set of manage¬ 
ment controls. 


These management controls are directed at 
individual information technology users in or¬ 
der to reflect the distributed nature of today’s 
technology. For security to be most effective, 
the controls must be a part of day-to-day opera¬ 
tions. This is best accomplished by planning for 
security not as a separate activity, but as part of 
overall planning. 

“Adequate security” is defined as “security 
commensurate with the risk and magnitude of 
harm from the loss, misuse, or unauthorized ac¬ 
cess to or modification of information.” This 
definition explicitly emphasizes the risk-based 
policy for cost-effective security established by 
the Computer Security Act. 86 

The new guidance assigns the Security Policy 
Board responsibility for (only) “national security 
policy coordination in accordance with the ap¬ 
propriate Presidential directive [e.g., PDD 29].” 87 
With respect to national security information: 

Where an agency processes information 
which is controlled for national security reasons 
pursuant to an Executive Order or statute, secu¬ 
rity measures required by appropriate directives 
should be included in agency systems. Those 
policies, procedures, and practices will be coor¬ 
dinated with the U.S. Security Policy Board as 
directed by the President. 88 

Otherwise, the proposed OMB guidance assigns 
government-wide responsibilities to agencies that 
are “consistent with the Computer Security Act.” 
These include the Commerce Department, 
through NIST; the Defense Department, through 
NSA; the Office of Personnel Management; the 
General Services Administration, and the Justice 
Department. 89 

A complete analysis of the proposed revision to 
Appendix III is beyond the scope of this back- 


84 Ed Springer. OMB, personal communication. Mar. 23. 1995. 

85 Office of Management and Budget, op. cit., footnote 83. 

86 Ibid., p. 4. 

87 Ibid., p. 15. 

88 Ibid., pp. 3-4. 

8 ® Ibid., pp. 14-16. 
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ground paper. In brief, the proposed new guidance 
reflects a fundamental and necessary shift in em¬ 
phasis from securing automated information sys¬ 
tems to safeguarding automated information 
itself. It seeks to accomplish this through: 

■ controls for general support systems (including 
hardware, software, information, data, applica¬ 
tions, and people) that share common function¬ 
ality and are under the same direct management 
control; and 

■ controls for major applications (that require 
special attention due to their mission-critical 
nature). 

For each type of control, OMB seeks to ensure 
managerial accountability by requiring manage¬ 
ment officials to authorize in writing, based on re¬ 
view of implementation of the relevant security 
plan, use of the system or application. For general 
support systems, OMB specifies that use should 
be re-authorized at least every three years. Simi¬ 
larly, major applications must be authorized be¬ 
fore operating and reauthorized at least every three 
years thereafter. For major applications, manage¬ 
ment authorization implies accepting the risk of 
each system used by the application. 90 

This type of active risk acceptance and account¬ 
ability, coupled with review and reporting require¬ 
ments, is intended to result in agencies ensuring 
that adequate resources are devoted to implement¬ 
ing “adequate security.” Every three years (or 
when significant modifications are made), agen¬ 
cies must review security controls in systems and 
major applications and correct deficiencies. De¬ 
pending on the severity, agencies must also con¬ 
sider identifying a deficiency in controls pursuant 
to the Federal Manager’s Financial Accountabil¬ 
ity Act. Agencies are required to include a sum¬ 
mary of their system security plans and major 
application security plans in the five-year plan re¬ 
quired by the Paperwork Reduction Act. 


IMPLICATIONS FOR 
CONGRESSIONAL ACTION 

The next sections discuss implications of the 
above for congressional actions related to cryp¬ 
tography policy and government information se¬ 
curity, in the context of issues and options OTA 
identified in its 1994 report Information Security 
and Privacy in Network Environmen ts (see appen¬ 
dix D of this paper and/or chapter 1 of the 1994 
report). 

I Export Controls and Standards 

Reform of the current export controls on cryptog¬ 
raphy was certainly the number one topic at the 
December 1994 OTA workshop. More generally, 
the private sector’s priority in this regard is indi¬ 
cated by the discussion of the industry statements 
of business needs above. Legislation would not be 
required to relax controls on cryptography, if this 
were done by revising the implementing regula¬ 
tions. However, the Clinton Administration has 
previously evidenced a disinclination to relax 
controls on robust cryptography, except perhaps 
for certain key-escrow encryption products. 91 

The Export Administration Act is to be reautho¬ 
rized in the 104th Congress. The issue of export 
controls on cryptography may arise during con¬ 
sideration of export legislation, or if new export 
procedures for key-escrow encryption products 
are announced, and/or when the Clinton Adminis¬ 
tration’s market study of cryptography and con¬ 
trols is completed this summer. Aside from any 
consideration of whether or not to include cryp¬ 
tography provisions in the 1995 export adminis¬ 
tration legislation. Congress could advance the 
convergence of government and private sector in¬ 
terests into some “feasible middle ground” 
through hearings, evaluation of the Administra¬ 
tion’s market study, and by encouraging a more 
timely, open, and productive dialogue between 


90 Ibid., pp. 2-6. 

91 See appendix C, especially footnote 10 and accompanying text. 
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government and the private sector (see pages 
11-13,150-160,174-179 ofthe 1994 OTA report.) 

Oversight of the implementation of the Comput¬ 
er Security Act is also important to cryptography 
policy considerations (see below). The cryptogra¬ 
phy-related federal information processing stan¬ 
dards still influence the overall market, and the 
development of recent FIPS (e.g., the DSS and 
EES) demonstrates a mismatch between the intent 
of the act and its implementation by NIST and 
NSA (see pp. 160-183 of the 1994 OTA report.). 
The attributes of these standards do not meet most 
users’ needs, and their deployment would benefit 
from congressional oversight, both in the strategic 
context of a policy review and as tactical response 
to the Clinton Administration’s escrowed-encryp¬ 
tion initiative (see pp. 16-20 of the 1994 OTA re¬ 
port). 

If the Computer Security Act is revisited, Con¬ 
gress might wish to redirect NIST’s activities 
away from “picking technologies” for standards 
(i.e., away from developing product-oriented 
FIPS like the EES) and toward providing federal 
agencies with guidance on: 

■ the availability of suitable commercial technol¬ 
ogies; 

■ interoperability and application portability; 
and 

■ how to make best use of existing hardware and 
software technology investments. 

Also, targeting NIST’s information-security acti¬ 
vities towai'd support of OMB’s proposed guid¬ 
ance (with its focus on end users and individual 
workstations) might enable NIST to be more ef¬ 
fective despite scarce resources. 

Finally, there has been very little information 
from the Clinton Administration as to the current 
and projected costs of the escrowed-encryption 
initiative, including costs of the escrow agencies 
for Clipper and Capstone chips and prices and ex¬ 
penditures for the FORTEZZA cards. The latter 
may be indicative of the likelihood of the 
“PCMCIA portfolio” FORTEZZA approach find¬ 
ing favor in the civil agencies and in the private 
sector, compared with more flexible and/or disag¬ 


gregate implementation of encryption and signa¬ 
ture functions. 

I Safeguarding Unclassified Information 
in the Federal Agencies 

The need for congressional oversight of federal 
information security and privacy is even more 
urgent in a time of government reform and stream¬ 
lining. When the role, size, and structure of the 
federal agencies are being reexamined, it is impor¬ 
tant to take into account the additional infor¬ 
mation security and privacy risks incurred in 
downsizing and the general lack of commitment 
by top agency management to safeguarding un¬ 
classified information. 

A major problem in the agencies has been lack of 
top management focus on, not to mention respon¬ 
sibility and accountability for, information securi¬ 
ty. As the 1994 OTA report on information 
security and privacy in network environments 
noted: 

The single most important step toward imple¬ 
menting proper information safeguards for net¬ 
worked information in a federal agency or other 
organization is for top management to define the 
organization's overall objectives and a security 
policy to reflect those objectives. Only top man¬ 
agement can consolidate the consensus and ap¬ 
ply the resources necessary to effectively 
protect networked information. For the federal 
government, this means guidance from OMB, 
commitment from top agency management, and 
oversight by Congress, (p. 7) 

All too often, agency managers have regarded 
information security as “expensive overhead” that 
could be skimped on, deferred, or foregone in fa¬ 
vor of other expenditures (e.g., for new computer 
hardware and applications). Any lack of priority 
and resources for safeguarding information is in¬ 
creasingly problematic as we move toward in¬ 
creased secondary use of data, data sharing across 
agencies, and decentralization of information 
processing and databases. If this mindset were 
permitted to continue during agency downsizing 
and program consolidation, the potential—and 
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realized—harms from “disasters waiting to hap¬ 
pen” can be much greater. (See pages 1-8, 25-31, 
and 40-43 of the 1994 OTA report.) For example, 
without proper attention to information security, 
staffing changes during agency restructuring and 
downsizing can increase security risks (due to un¬ 
staffed or understaffed security functions, reduc¬ 
tions in security training and implementation, 
large numbers of disgruntled former employees, 
etc.). 

OTA’s ongoing work has spotlighted important 
elements of good information-security practice in 
the private sector, including active risk acceptance 
by line management. The concept of management 
responsibility and accountability as integral com¬ 
ponents of information security, rather than just 
“handing off’ security to technology, is very im¬ 
portant. 

Sound security policies as a foundation for prac¬ 
tice are essential; these should be technology neu¬ 
tral. Technology-neutral policies specify what 
must be done, not how to do it. Because they do 
not prescribe implementations, technology-neu¬ 
tral policies are longer lived. They are not so easi¬ 
ly obsoleted by changes in technology or business 
practices; they allow for local customization of 
implementations to meet operational require¬ 
ments. Once these are in place, security imple¬ 
mentation should be audited against policy, not 
against implementation guidelines . This helps 
prevent confusing implementation techniques and 
tools (e.g., use of a particular' type of encryption or 
use of an computer operating system with a certain 
rating) with policy objectives, and discourages 
“passive risk acceptance” like mandating use of a 
particular' technology. This also allows for flexi¬ 
bility and customization. 

In the federal arena, however, more visible ener¬ 
gy seems to be have been focused on debates over 
implementation tools—that is, federal informa¬ 
tion processing standards like the Data Encryption 
Standard, Digital Signature Standard, and Es¬ 
crowed Encryption Standard—than on formulat¬ 
ing enduring, technology-neutral policy guidance 
for the agencies. 


Direction of Revised 0MB Guidance 

In the 1994 report Information Security and Pri¬ 
vacy in Network Environments, OTA identified 
the need for the revised version of the security ap¬ 
pendix (Appendix III) of OMB Circular A-130 to 
adequately address problems of managerial re¬ 
sponsibility and accountability, insufficient re¬ 
sources devoted to information security, and 
overemphasis on technology, as opposed to man¬ 
agement. In particular, OTA noted the importance 
of making agency line management (not just “in¬ 
formation security officers”) accountable for in¬ 
formation security and ensuring that privacy and 
other policy objectives are met. Moreover, OTA 
noted that the proposed new OMB guidance 
would have to provide sufficient incentives—es¬ 
pecially in times of budget cuts—to ensure that 
agencies devote adequate resources to safeguard¬ 
ing information. Similarly, the OMB guidance 
would have to ensure that information safeguards 
are treated as an integral component when systems 
are designed or modified. 

The proposed revision to Appendix III of OMB 
Circular A-130, as discussed above, shows prom¬ 
ise for meeting these objectives. OMB’s proposed 
guidance is intended to incorporate critical ele¬ 
ments of considering security as integral (rather 
than an add-on) to planning and operations, active 
risk acceptance, line management responsibility 
and accountability, and focus on management and 
people rather than technology. Taken as a whole, 
these elements are intended to provide sufficient 
incentives for agency managements to devote ade¬ 
quate resources to security; the review and report¬ 
ing requirements offer disincentives for 
inadequate security. Moreover, if implemented 
properly, the new OMB approach can make sig¬ 
nificant progress in the ultimate goal of tracking 
and securing the information itself, as it is gath¬ 
ered, stored, processed, and shared among users 
and applications. 

However, OMB’s twofold approach is some¬ 
what abstract and a significant departure from ear¬ 
lier, “computer security” guidance. Therefore, 
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congressional review and oversight of OMB’s 
proposed revisions to Appendix III, as suggested 
in the 1994 OTA report (see appendix D and pages 
18-20 of the 1994 OTA report), would be helpful 
in ensuring that Congress, as well as federal agen¬ 
cies and the public, understand the new informa¬ 
tion-security guidance and how OMB intends for 
its new approach to be implemented. 

This congressional review and oversight might 
also provide additional guidance on how NIST’s 
security activities might best be refocused to meet 
federal information-security objectives. For ex¬ 
ample, in addition to Commerce’s (i.e., NIST’s) 
traditional responsibilities for security standards 
and training and awareness, the new Appendix III 
assigns Commerce responsibilities for providing 
agencies with guidance and assistance concerning 
effective controls when systems are intercon¬ 
nected, coordinating incident response activities 
to promote information-sharing regarding inci¬ 
dents and related vulnerabilities, and (with De¬ 
fense technical assistance) evaluating new 
information technologies to assess their security 
vulnerabilities and apprising agencies of these in a 
timely fashion. 92 

Locus of Authority 

Another reason for the importance and timeliness 
of congressional oversight of government-wide 
information-security policy guidance is that there 
is momentum for extending the defense/intelli¬ 
gence community’s centralization of information- 
security responsibilities throughout the civil 
agencies as well. If initiatives such as the Informa¬ 
tion Systems Security Committee structure pres¬ 
ented in the Security Policy Board’s staff report 
come to fruition, information-security responsibi¬ 
lities for both the civilian agencies and the de¬ 
fense/intelligence agencies would be merged. 

An overarching issue that must be resolved by 
Congress is where federal authority for safeguard¬ 
ing unclassified information in the civilian agen¬ 


cies should reside and, therefore, what needs to be 
done concerning the substance and implementa¬ 
tion of the Computer Security Act of 1987. If Con¬ 
gress retains the general premise of the act—that 
responsibility for unclassified information securi¬ 
ty in the civilian agencies should not be placed 
within the defense/intelligene community—then 
vigilant oversight and clear direction will be need¬ 
ed to ensure effective implementation, including 
assigning and funding a credible focal point for 
unclassified information security (see discussion 
of OMB Appendix III above and also pp. 19-20 of 
the 1994 OTA report). 

Without doubt, leadership and expertise are 
needed for better, more consistent safeguarding of 
unclassified information government-wide. But it 
is not clear that there are no workable alternatives 
to centralizing government-wide information-se¬ 
curity responsibilities under the defense/intelli¬ 
gence community. Proposals to do so note current 
information-security deficiencies; however, 
many of these can be attributed to lack of commit¬ 
ment to and funding for establishment of an alter¬ 
native source of expertise and technical guidance 
for the civilian agencies. For example, the “effi¬ 
ciency” arguments (see below) made in the Joint 
Security Commission report and the Security 
Policy Board staff report for extending the respon¬ 
sibilities of the defense/intelligence community 
to encompass governmentwide security for classi¬ 
fied and unclassified information capitalize on the 
vacuum in leadership and expertise created by 
chronic underfunding of the designated civilian 
agency—at present, NIST. (See pp. 13-16, 20, 
138-150, and 182-183 of the 1994 OTA report.) 

Proposals for centralizing security responsibili¬ 
ties for both classified and unclassified informa¬ 
tion government-wide offer efficiency arguments 
to the effect that: 

1. security policies, practices, and procedures (as 
well as technologies) for unclassified informa- 


92 OMB, op. cit., footnote 83, p. 7. 


Chapter 4 Implications for Congressional Action 1101 


tion are for the most part spinoffs from the clas¬ 
sified domain; 

2. the defense and intelligence agencies are expert 
in classified information security; and there¬ 
fore 

3. the unclassified domain can best be served by 
extending the authority of the defense/intelli¬ 
gence agencies. 

The validity of the “spinoff’ assumption about 
unclassified information security is questionable. 
There arc real questions about NSA’s ability to 
place the right emphasis on cost-effectiveness, as 
opposed to absolute effectiveness, in flexibly de¬ 
termining the most appropriate means for safe¬ 
guarding unclassified information. Due to its 
primary mission in securing classified informa¬ 
tion, NSA’s traditional culture tends toward a 
standard of absolute effectiveness, not trading off 
cost and effectiveness. By contrast, the Computer 
Security Act of 1987, the Paperwork Reduction 
Act of 1995, and the new, proposed revision of 
OMB Appendix III all require agencies to identify 
and employ cost-effective safeguards, for exam¬ 
ple: 

With respect to privacy and security, the Di¬ 
rector [of OMB] shall . . . require Federal agen¬ 
cies, consistent with the Computer Security Act 
of 1987 (940 U.S.C. 759 note) security protec¬ 
tions commensurate with the risk and magnitude 
of the harm resulting from the loss, misuse, or 
unauthorized access to or modification of in¬ 
formation collected or maintained by or on be¬ 
half of an agency. 93 

Moreover, the current state of government secu¬ 
rity practice for unclassified information has been 


depressed by the chronic shortage of resources for 
NIST’s computer security activities in fulfillment 
of its government-wide responsibilities under the 
Computer Security Act of 1987. Since enactment 
of the Computer Security Act, there has been no 
serious (i.e., adequately funded and properly 
staffed), sustained effort to establish a center of in- 
formation-security expertise and leadership out¬ 
side the defense/intelligence communities. 

Even if the efficiency argument is attractive, 
Congress would still need to consider whether the 
gains would be sufficient to overcome the con¬ 
comitant decrease in “openness” in information- 
security policymaking and implementation, 
and/or whether the outcomes would fall at an ac¬ 
ceptable point along the “efficiency-openness” 
possibility frontier. In the area of export controls 
on cryptography, for example, there is substantial 
public concern with the current tradeoff between 
the needs of the defense/intelligence and the busi¬ 
ness/user communities. With respect to informa¬ 
tion-security standards and guidelines, there has 
been continuing concern with the lack of openness 
and accountability in policies formulated and im¬ 
plemented under executive order, rather than 
through the legislative process. It would be diffi¬ 
cult to formulate a scenario in which increasing 
the defense/intelligence community’s authority 
government-wide would result in more openness 
or assuage public concerns. (In the 1980s, con¬ 
cerns over NSDD-145’s placement of govern¬ 
mental authority for unclassified information 
security within the defense/intelligence commu¬ 
nity led to enactment of the Computer Security 
Act of 1987.) 


93 “ 


‘Paperwork Reduction Act of 1995” (S. 244), section 3504(g)(3), Mar. 7, 1995, Federal Record , p. S3557. 
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Dear Dr. Herdman: 

Thank you again for the fine report. Information _ 

Security aria privacy In Network Environments. As you may 
recall, that report was prepared in response to our interest 
in how government policies must adapt to changes in 
communications network technologies that affect the privacy 
and economic livelihood of every American. The report 
highlights key issues and makes recommendations that should 
serve as the basis for hearings and legislation. Towards that 
end, we are Writing to ask for your assistance in working with 
our stgff to ,follow-up and develop .further the findings of the 
report.. _'_ ’ - 
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We would appreciate it if the project director, Ms, 

s tem. — hp gj_owi- e^ntf and —feo-i 


assist our staff in preparing for hea rings and subseque nt 
legislation. In particular, we request analytical support on 
policy requirements and alternatives, including further 

insights in r nmnnl-ar network pr^t>1 nsifl the 

survivability and reliability of such networks. In addition, 
the Committee needs information gathered from industry. 
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raised in the report, including rele vant implications of_ 
emerging technology. In carrying out this request, we would 
also like the Office of Technology Assessment to host a 
meetincr with t* ivoc -°r.d 

academia to discuss the findings of the report. 
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underscores the fact that much more work must be done. There 
are many questions about' the role of government that the 


Governmental Affairs Committee must address. We would 
appreciate your continued cooperation. 


Sincerely, 


William V. Roth, Jr._ 

Ranking Republican Member 


^lenn 

Chairman 


Appendix B: 
Federal Information 
Security and the 
Computer Security Act 



T his appendix draws on chapter 4 of the 
September 1994 OTA report Information 
Security and Privacy in Network Environ¬ 
ments, 1 with updates as noted herein. That 
chapter of the 1994 report examined the policy 
framework within which federal agencies formu¬ 
late and implement their information-security and 
privacy policies and guidelines. Because of its im¬ 
portance for federal government information se¬ 
curity and cryptography policy, the Computer 
Security Act of 1987 (Public Law 100-235) was 
examined in detail. 

The Computer Security Act of 1987 estab¬ 
lished a federal government computer-security 
program that would protect sensitive information 
in federal government computer systems and 
would develop standards and guidelines for un¬ 
classified federal computer systems to facilitate 
such protection. Specifically, the Computer Secu¬ 
rity Act assigned responsibility for developing 
government-wide, computer-system security 
standards and guidelines and security-training 
programs to the National Bureau of Standards 
(now the National Institute of Standards and 


Technology, or NIST). The act also established a 
Computer System Security and Privacy Advisory 
Board within the Commerce Department. Addi¬ 
tionally, the act required federal agencies to iden¬ 
tify computer systems containing sensitive 
information, to develop security plans for identi¬ 
fied systems, and to provide periodic training in 
computer security for all federal employees and 
contractors who manage, use, or operate federal 
computer systems. 

In Information Security and Privacy in Net¬ 
work Environments , OTA found that implementa¬ 
tion of the Computer Security Act has been 
problematic (see chapter 4 of the 1994 report). In 
workshop discussions and interviews during and 
after the assessment, OTA found strong sentiment 
that agencies follow the rules set forth by the act 
regarding security plans and training, but do not 
necessarily fulfill the intent of the act. For exam¬ 
ple, agencies are required to develop security 
plans—and do—but may not “do the plan” or up¬ 
date plans and implementation in a timely fashion 
to reflect changes in technology or operations (see 
section on implementation issues below). 


1 U.S. Congress, Office of Technology Assessment, Information Security and Privacy in Network Environments, OTA-TCT-606 (Washing¬ 
ton, DC: U.S. Government Printing Office, September 1994). 
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Implementation of the Computer Security Act 
has been especially controversial regarding the 
roles of NIST and National Security Agency 
(NSA) in standards development for unclassified 
federal computer systems. The act was designed 
to balance national security and other national ob¬ 
jectives, giving what is now the National Institute 
of Standards and Technology the lead in develop¬ 
ing security standards and guidelines and defining 
the role of NSA as technical advisor to NIST. 2 
However, events subsequent to the act have not 
convincingly demonstrated NIST’s leadership in 
this area. In OTA’s view, NSA has enjoyed de fac¬ 
to leadership in the development of cryptographic 
standards and technical guidelines for unclassi¬ 
fied information security, and implementation of 
the act has not fulfilled congressional intent in this 
respect. 3 

EVOLUTION OF POLICY FRAMEWORK 
FOR UNCLASSIFIED INFORMATION 
SECURITY 4 

Statutory guidance on safeguarding information 
provides a policy framework—in terms of techni¬ 
cal and institutional requirements and managerial 
responsibilities—for government information 
and information-system security. Overlaid on this 
are statutory privacy requirements that set forth 
policies concerning the dissemination and use of 
certain types of information about individuals. 
Within this framework, and subject to their own 
specific statutory requirements, federal agencies 
and departments develop their policies and guide¬ 
lines, in order to meet individual and government¬ 
wide security and privacy objectives. 


The Privacy Act of 1974 (Public Law 93-579) 
set forth data collection, confidentiality, proce¬ 
dural, and accountability requirements federal 
agencies must meet to prevent unlawful invasions 
of personal privacy, and provides remedies for 
noncompliance. It does not mandate use of specif¬ 
ic technological measures to accomplish these re¬ 
quirements. Other statutes set forth information 
confidentiality and integrity requirements for spe¬ 
cific agencies, such as the Internal Revenue Ser¬ 
vice, Bureau of the Census, and so forth. (Issues 
related to the Privacy Act, and other, international 
privacy issues are discussed in chapter 3 of the 
1994 OTA report.) 

The Brooks Act of 1965 (Public Law 89-306) 
was enacted to “provide for the economic and effi¬ 
cient purchase, lease, maintenance, operation, and 
utilization of automatic data processing [ADP] 
equipment by federal departments and agencies.” 
[OTA note: New procurement legislation in the 
104th Congress may supersede the Brooks Act.] 
The Warner Amendment (Public Law 97-86) sub¬ 
sequently exempted certain types of Defense De¬ 
partment procurements from the Brooks Act (and 
from section 111 of the Federal Property and Ad¬ 
ministrative Services Act of 1949). 

Among other provisions, the Brooks Act made 
the Commerce Department the focal point for pro¬ 
mulgation of government “automatic data proc¬ 
essing” (i.e., computer and information-system) 
standards and authorized Commerce to conduct a 
research program to support standards develop¬ 
ment and assist federal agencies in implementing 
these standards. These responsibilities were car- 


- NIST recommends standards and guidelines to the Secretary of Commerce for promulgation. Such standards and guidelines would apply 
to federal computer systems, except for: 1) those systems excluded by section 2315 of Title 10, USC or section 3502(2) of Title 44, USC; and 2) 
those systems protected at all times by procedures established for information classified by statute or executive order (Public Law 100-235, 
section 3). The first, “Warner Amendment,” exclusion pertains, for example, to intelligence or national security cryptologic systems, mission- 
critical military or intelligence systems, or systems involving the direct command and control of military forces. 

3 See OTA, op. cit., footnote 1, pp. 138-148, 182-184. See also U.S. General Accounting Office, Communications Privacy: Federal Policy 
and Actions, GAO/OSI-94-2 (Washington, DC: U.S. Government Printing Office, November 1993). 

4 This is taken from OTA, op. cit., footnote 1, ch. 4, esp. pp. 132-138. 


Appendix B Federal Information Security and the Computer Security Act 1107 


ried out by the National Bureau of Standards (now 
NIST). 

NBS established its program in computer and 
communications security in 1973. under authority 
of the Brooks Act; the agency was already devel¬ 
oping performance standards for government 
computers. This security program led to the adop¬ 
tion of the Data Encryption Standard (DES) as a 
federal information processing standard (FIPS) 
for use in safeguarding unclassified information. 
The security responsibilities of what is now 
NIST’s Computer Systems Laboratory (CSL) 
were affirmed and extended by the Computer Se¬ 
curity Act of 1987. 

The Paperwork Reduction Act of 1980 (Pub¬ 
lic Law 96-511) gave agencies a broad mandate to 
perform their information-management activities 
in an efficient, effective, and economical manner. 
| OTA note: The Paperwork Reduction Act of 1995 
was reported on April 3, 1995, and was cleared 
for the White House on April 6, 1995. The 1995 
legislation is discussed in chapter 4 of this back¬ 
ground paper. The historical discussion below re¬ 
fers to the 1980 law.] 

The Paperwork Reduction Act of 1980 as¬ 
signed the Office of Management and Budget 
(OMB) responsibilities for maintaining a compre¬ 
hensive set of information resources management 
policies and for promoting the use of information 
technology to improve the use and dissemination 
of information by federal agencies. OMB was giv¬ 
en authority for the following: developing and im¬ 
plementing uniform and consistent information 
resource management policies; overseeing the de¬ 
velopment of and promoting the use of gov¬ 
ernment information management principles, 
standards, and guidelines; evaluating the adequa¬ 
cy and efficiency of agency information manage¬ 
ment practices; and determining whether these 
practices comply with the policies, principles, 
standards, and guidelines promulgated by the di¬ 
rector of OMB. 

OMB Circular A-130 (“Management of Fed¬ 
eral Information Resources”) was originally is¬ 
sued in 1985 to fulfill these and other statutory 
requirements (including the Privacy Act). Circu¬ 
lar A-130 revised and consolidated policies and 


procedures from several other OMB directives, 
which were rescinded. OMB Circular A-130 has 
recently been revised. The first stage of revisions 
(June 1993) focused on information exchanges 
with the public; the second stage addressed 
agency management practices for information 
technology and information systems (July 1994). 
The third stage, addressing security controls and 
responsibilities in Appendix III of the circular, is 
ongoing at this writing. 

[OTA note: The historical overview of policy 
development below refers to the 1985 version of 
Appendix III. OMB’s 1995 proposed revision of 
Appendix III is discussed in chapter 4 of this back¬ 
ground paper. ] 

Appendix III of OMB Circular A-130 (1985) 
addressed the “Security of Federal Automated In¬ 
formation Systems.” Its puipose was to establish a 
minimal set of controls to be included in federal 
information systems security programs, assign re¬ 
sponsibilities for the security of agency informa¬ 
tion systems, and clarify the relationship between 
these agency controls and security programs and 
the requirements of OMB Circular A-123 (“Inter¬ 
nal Control Systems”). The 1985 appendix also 
incorporated responsibilities from applicable na¬ 
tional security directives. 

Section 4(a) of the 1985 version of the security 
appendix of OMB Circular A-130 assigned the 
Commerce Department responsibility for: 

1. developing and issuing standards and guide¬ 
lines for assuring the security of federal in¬ 
formation systems; 

2. establishing standards “approved in accor¬ 
dance with applicable national security direc¬ 
tives,” for systems used to process “sensitive” 
information, “the loss of which could adversely 
affect the national security interest;” and 

3. providing technical support to agencies in im¬ 
plementing Commerce Department standards 
and guidelines. 

According to the 1985 Appendix III, the Defense 
Department was to act as the executive agent of 
the government for the security of telecommu¬ 
nications and information systems that process in¬ 
formation, “the loss of which could adversely 
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affect the national security interest” (i.e., includ¬ 
ing information that was unclassified but was con¬ 
sidered “sensitive”), and was to provide technical 
material and assistance to federal agencies con¬ 
cerning the security of telecommunications and 
information systems. 

These responsibilities later shifted (see below) 
in accordance with the Computer Security Act of 
1987 and the subsequent National Security Direc¬ 
tive 42 (NSD 42). After the Computer Security 
Act was enacted, NSD 42 set the leadership re¬ 
sponsibilities of the Commerce and Defense De¬ 
partments according to whether the information 
domain was outside or within the area of “national 
security.” 5 

The Computer Security Act of 1987 (Public 
Law 100-235) affirmed and expanded the comput¬ 
er-security research and standards responsibilities 
of NBS (now NIST) and gave it the responsibility 
for developing computer system security training 
programs and for commenting on agency comput¬ 
er system security plans. The Computer Security 
Act is particularly important because it is funda¬ 
mental to the development of federal standards for 
safeguarding unclassified information, to the bal¬ 
ance between national security and other objec¬ 
tives in implementing security and privacy 
policies within the federal government, and to is¬ 
sues concerning government control of cryptogra¬ 


phy. Moreover, review of the controversies and 
debate surrounding the Computer Security Act— 
and subsequent controversies over its implemen¬ 
tation—provides background for understanding 
current issues. 

THE COMPUTER SECURITY ACT 6 

The Computer Security Act of 1987 (Public Law 
100-235) 7 was a legislative response to overlap¬ 
ping responsibilities for computer security among 
several federal agencies, heightened awareness of 
computer security issues, and concern over how 
best to control information in computerized or 
networked form. As noted above, the act estab¬ 
lished a federal government computer-security 
program that would protect sensitive information 
in federal government computer systems and 
would develop standards and guidelines for un¬ 
classified federal computer systems to facilitate 
such protection. 8 Additionally, the act required 
federal agencies to identify computer systems 
containing sensitive information, to develop secu¬ 
rity plans for identified systems, and to provide 
periodic training in computer security for all fed¬ 
eral employees and contractors who manage, use, 
or operate federal computer systems. The act also 
established a Computer System Security and Pri¬ 
vacy Advisory Board within the Commerce De- 


5 The Computer Security Act of 1987 gave the Commerce Department responsibility in information domains that contained information 
that was “sensitive” but not classified for national security purposes. National Security Directive 42 (National Policy for the Security of Nation¬ 
al Security [emphasis added] Telecommunications and Information Systems, July 5,1990) established a National Security Telecommunications 
and Information Systems Security Committee (NSTISSC), made the Secretary of Defense the Executive Agent of the Government for National 
Security Telecommunications and Information Systems, and designated the Director of NSA as the National Manager for National Security 
Telecommunications and Information Systems. [OTA note: This information-security structure may be superseded by a new structure under the 
Security Policy Board, wherein NSTISSC’s functions would be incorporated into the functions of a new Information Systems Security Commit¬ 
tee. See chapter 4 and box 1-3 of this paper for discussion of the Security Policy Board.] 

6 This is taken from OTA, op. cit., footnote 1, ch. 4. See pp. 140-142 of that report for legislative history of the Computer Security Act. 

7 101 Stat. 1724. 

8 The act was “[t]o provide for a computer standards program within the National Bureau of Standards, to provide for government-wide 
computer security, and to provide for the training in security matters of persons who are involved in the management, operation, and use of 
federal computer systems, and for other purposes” (ibid.). Specifically, the Computer Security Act assigned responsibility for developing gov¬ 
ernment-wide, computer-system security standards and guidelines and security-training programs to the National Bureau of Standards (now 
the National Institute of Standards and Technology). NBS (now NIST) would recommend these to the Secretary of Commerce for promulga¬ 
tion. 
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partment. (The Computer Security Act and a 
controversial 1989 Memorandum of Understand¬ 
ing (MOU) laying out the working relationship 
between NIST and NSA to implement the act are 
contained in appendix B of the 1994 OTA report). 

Congressional concerns and public awareness 
created a climate conducive to passage of the 
Computer Security Act of 1987. Highly publi¬ 
cized incidents of unauthorized users, or “hack¬ 
ers,” gaining access to computer systems and a 
growing realization of the government’s depen¬ 
dence on information technologies renewed na¬ 
tional interest in computer security in the early 
1980s. 9 

Disputes over how to control unclassified in¬ 
formation also prompted passage of the act. The 
Reagan Administration had sought to give the Na¬ 
tional Security Agency much control over what 
was termed “sensitive, but unclassified” informa¬ 
tion, while the public—especially the academic, 
banking, and business communities—viewed 
NSA as an inappropriate agency for such respon¬ 
sibility. The Reagan Administration favored an 
expanded concept of national security. 10 This ex¬ 
panded concept was embodied in subsequent 
presidential policy directives (see below), which 
in turn expanded NSA’s control over computer se¬ 
curity. Questions regarding the role of NSA in se¬ 
curity for unclassified information, the types of 
information requiring protection, and the general 
amount of security needed, all divided the Reagan 


Administration and the scientific community in 
the 1980s. 11 

I Agency Responsibilities Before the Act 

Some level of federal computer-security responsi¬ 
bility rests with the Office of Management and 
Budget, the General Services Administration 
(GSA), and the Commerce Department (specifi¬ 
cally NIST and the National Telecommunications 
and Information Administration (NTIA)). OMB 
maintains overall responsibility for computer se¬ 
curity policy. 12 GSA issues regulations for physi¬ 
cal security of computer facilities and oversees 
technological and fiscal specifications for security 
hardware and software. 13 In addition to its other 
responsibilities, NSA traditionally has been re¬ 
sponsible for security of information that is classi¬ 
fied for national security puiposes, including 
Defense Department information. 14 Under the 
Brooks Act, Commerce develops the federal in¬ 
formation processing standards that provide 
specific codes, languages, procedures, and tech¬ 
niques for use by federal information systems 
managers. 15 NTIA serves as the executive branch 
developer of federal telecommunications 
policy. 16 

These overlapping agency responsibilities hin¬ 
dered the development of one uniform federal 
policy regarding the security of unclassified in¬ 
formation, particularly because computer security 


9 U.S. Congress, Office of Technology Assessment. Federal Government Information Technology: Management. Security and Congres- 
sional Oversight, OTA-CIT-297 (Washington, DC: U.S. Government Printing Office, February 1986), pp. 64-65. 

10 See, e.g., Harold Relyea, Silencing Science: National Security Controls and Scientific Communication (Norwood, NJ: Ablex, 1994). 

11 See, e.g., John T. Soma and Elizabeth J. Bedient, “Computer Security and the Protection of Sensitive but Not Classified Data: The Com¬ 
puter Security Act of 1987,” Air Force Law Review, vol. 30, 1989, p. 135. 

12 U.S. Congress, House of Representatives, Committee on Science, Space, and Technology, Computer Security Act of 1987—Report to 
Accompany H.R. 145, H. Rept. 100-153, Parti, 100th Cong., 1st sess., June 11,1987 (Washington, DC: U.S. Government Printing Office, 1987), 
p.7. 

13 Ibid. 

14 Ibid. 

15 Ibid. The FIPS apply to federal agencies, but some, like the DES, have been adopted in voluntary, industry standards and are used in the 
private sector. The FIPS are developed by NIST and approved by the Secretary of Commerce. 

16 Ibid. 
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and communications security historically have 
developed separately. In 1978. OMB had issued 
Transmittal Memorandum No. 1 (TM-1) to its 
Circular A-71. which addressed the management 
of federal information technology. 17 TM-1 re¬ 
quired federal agencies to implement computer 
security programs, but a 1982 General Account¬ 
ing Office (GAO) report concluded that Circular 
A-71 (and its TM-1) had failed to provide clear 
guidance. 18 

Executive orders in the 1980s, specifically the 
September 1984 National Security Decision Di¬ 
rective 145, “National Policy on Telecommu¬ 
nications and Automated Information Systems 
Security” (NSDD-145), 19 created significant 
shifts and overlaps in agency responsibilities. Re¬ 
solving these was an important objective of the 
Computer Security Act. NSDD-145 addressed 
safeguards for federal systems that process or 
communicate unclassified, but “sensitive” in¬ 
formation. NSDD-145 established a Systems Se¬ 
curity Steering Group to oversee the directive and 
its implementation, and an interagency National 
Telecommunications and Information Systems 
Security Committee (NTISSC) to guide imple¬ 
mentation under the direction of the steering 
group. 20 

I Expanded NSA Responsibilities 
Under NSDD-145 

In 1980, Executive Order 12333 had designated 
the Secretary of Defense as Executive Agent of the 
Government for Communications Security. 
NSDD-145 expanded this role to encompass tele¬ 
communications and information systems securi¬ 
ty and responsibility for implementing policies 


developed by NTISSC. The Director of NSA was 
designated National Manager for Telecommu¬ 
nications and Automated Information Systems 
Security. The national manager was to implement 
the Secretary of Defense’s responsibilities under 
NSDD-145. As a result, NSA was charged with 
examining government information and telecom¬ 
munications systems to evaluate their vulnerabili¬ 
ties, as well as with reviewing and approving all 
standards, techniques, systems, and equipment 
for telecommunications and information systems 
security. 

In 1985, the Office of Management and Budget 
issued another circular concerning computer se¬ 
curity. This OMB Circular A-130, “Management 
of Federal Information Resources,” revised and 
superseded Circular A-71 (see previous section). 
OMB Circular A-130 defined security, encour¬ 
aged agencies to consider information security es¬ 
sential to internal control reviews, and clarified 
the definition of “sensitive” information to in¬ 
clude information “whose improper use or disclo¬ 
sure could adversely affect the ability of an agency 
to accomplish its mission . . . ,” 21 

In 1986, presidential National Security Adviser 
John Poindexter 22 issued “National Telecommu¬ 
nications and Information Systems Security 
Policy Directive No. 2” (NTISSP No. 2). NTISSP 
No. 2 proposed a new definition of “sensitive but 
unclassified information.” It potentially could 
have restricted access to information that pre¬ 
viously had been available to the public. Specifi¬ 
cally, “sensitive but unclassified information,” 
within the meaning set forth in the directive, in¬ 
cluded not only information which, if revealed, 
could adversely affect national security, but also 


17 Office of Management and Budget, Transmittal Memorandum No. 1 to OMB Circular A-71, 1978. 

18 U.S. General Accounting Office. Federal Information Systems Remain Highly Vulnerable to Fraudulent, Wasteful, Abusive, and Illegal 
Practices (Washington, DC: U.S. Government Printing Office, 1982). 

19 NSDD-145 is classified. An unclassified version was used as the basis for this discussion. 

20 This became the National Security Telecommunications and Information Systems Security Committee, or NSTISSC. See footnote 5. 

21 Office of Management and Budget, OMB Circular A-130 (1985). At this writing, the proposed revision of Appendix III of A-130 had just 
been published. The main section of A-130 was revised and issued in 1993. 

22 Adm. Poindexter was also chairman of the NSDD-145 Systems Security Steering Group (NSDD-145, sec. 4). 
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information that could adversely affect “other fed¬ 
eral government interests” if released. Other fed¬ 
eral government interests included economic, 
financial, technological, industrial, agricultural, 
and law enforcement interests. 

Such an inclusive directive sparked enormous, 
negative public response. As the Deputy Director 
of NBS stated during 1987 hearings on the Com¬ 
puter Security Act, the NTISSP No. 2 definition 
of sensitive information was a “totally inclusiona¬ 
ry definition. . . [tjhere is no data that anyone 
would spend money on that is not covered by that 
definition.” 23 Opponents of NSDD-145 and 
NTISSP No. 2 argued that NSA should not have 
control over federal computer security systems 
that did not contain classified information. 24 The 
business community, in particular, expressed con¬ 
cern about NSA’s ability and suitability to meet 
the private sector’s needs and hesitated to adopt 
NSA’s cryptographic technology in lieu of the 
DES. At the time, the DES was up for recertifica¬ 
tion. 25 In the House Report accompanying H.R. 
145, the Committee on Science, Space and 
Technology noted that: 

NSDD-145 can be interpreted to give the na¬ 
tional security community too great a role in set¬ 
ting computer security standards for civil 
agencies. Although the [Reagan] Administra¬ 
tion has indicated its intention to address this is¬ 
sue, the Committee felt it is important to pursue 
a legislative remedy to establish a civilian au¬ 
thority to develop standards relating to sensi¬ 
tive, but unclassified data. 26 


In its explanation of the bill, the committee also 
noted that: 

One reason for the assignment of responsibil¬ 
ity to NBS for developing federal computer sys¬ 
tem security standards and guidelines for 
sensitive information derives from the commit¬ 
tee’s concern about the implementation of Na¬ 
tional Security Decision Directive-145. 

. . . While supporting the need for a focal 
point to deal with the government computer se¬ 
curity problem, the Committee is concerned 
about the perception that the NTISSC favors 
military and intelligence agencies. It is also con¬ 
cerned about how broadly NTISSC might inter¬ 
pret its authority over “other sensitive national 
security information.” For this reason, H.R. 145 
creates a civilian counterpart, within NBS, for 
setting policy with regard to unclassified in¬ 
formation. . . NBS is required to work closely 
with other agencies and institutions such as 
NSA, both to avoid duplication and to assure 
that its standards and guidelines are consistent 
and compatible with standards and guidelines 
developed for classified systems; but the final 
authority for developing the standards and 
guidelines for sensitive information rests with 
the NBS. 27 

In its report on H.R. 145, the Committee on 
Government Operations explicitly noted that the 
bill was “neutral” with respect to public disclosure 
of information and was not to be used by agencies 
to exercise control over privately owned informa¬ 
tion, public domain information, or information 


- ' Raymond Kammer, Deputy Director, National Bureau of Standards, testimony, “Computer Security Act of1987: Hearings on H.R. 145 
Before the Subcommittee on Legislation and National Security of the House Committee on Government Operations, ” 100th Cong., 1st Sess., 
Feb. 26, 1987. See also H. Rept. 100-153, Part I, op. cit., footnote 12, p. 18. 

24 See U.S. Congress, House of Representatives, Committee on Science, Space and Technology, Computer Security Act of1987: Hearings 
on H.R. 145 Before the Subcommittee on Science, Research, and Technology and the Subcommittee on Transportation, Aviation, and Materials 
of the House Committee on Science, Space, and Technology, 100th Cong., 1st sess. (Washington, DC: U.S. Government Printing Office, 1987), 
pp. 146-191. 

25 Despite NSA’s desire to replace the DES with a family of tamper proof cryptographic modules using classified algorithms, the DES was 
reaffirmed in 1988. 

26 H. Rept. 100-153, Part I, op. cit., footnote 12, p. 22. 

27 Ibid., p. 26. 
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disclosable under the Freedom of Information Act 
or other laws. 28 Furthermore, the committee 
noted that H.R. 145 was developed in large paid to 
ensure the delicate balance between “the need to 
protect national security and the need to pursue the 
promise that the intellectual genius of America of¬ 
fers us.” 29 The committee also noted that: 

Since it is a natural tendency of DOD to re¬ 
strict access to information through the classifi¬ 
cation process, it would be almost impossible 
for the Department to strike an objective bal¬ 
ance between the need to safeguard information 
and the need to maintain the free exchange of in¬ 
formation. 30 

Subsequent to the Computer Security Act of 
1987, the Defense Department’s responsibilities 
under NSDD-145 were aligned by National Secu¬ 
rity Directive 42 to cover “national security” tele¬ 
communications and information systems. 31 
NSD 42 did not rescind programs, such as those 
begun under NSDD-145, that pertained to nation¬ 
al security systems, but these were not construed 
as applying to systems within the purview of the 
Computer Security Act of 1987. 32 

NSD 42 established the National Security Tele¬ 
communications and Information Systems Secu¬ 
rity Committee, made the Secretary of Defense 
the Executive Agent of the Government for Na¬ 
tional Security Telecommunications and Informa¬ 
tion Systems, and designated the Director of NS A 
the National Manager for National Security Tele¬ 
communications and Information Systems. 33 As 
such, the NS A Director was to coordinate with 


NIST in accordance with the Computer Security 
Act of 1987. 

[OTA note: The proposal for a new, govern¬ 
ment-wide centralization of unclassified informa¬ 
tion security, as presented in the November 1994 
Security Policy Board staff report, would place 
the functions of NSTISSC, along with OMB’s 
functions pursuant to Circular A-130, within a 
new Information Systems Security Committee 
chaired by DOD and OMB, with NSA as the secre¬ 
tariat. The staff report noted that this was con¬ 
trary to the Computer Security Act and suggested 
the need for a strategy to ensure a “smooth transi¬ 
tion’’ to the new structure, including creating a 
new definition for “national security related in¬ 
formation. 34 ” See chapter 4 and box 1-3 of this 
background paper for discussion of the Board 
staff proposal, along with discussions of other de¬ 
velopments, including OMB’s proposed revision 
of Appendix III of OMB Circular A-130 and the 
Paperwork Reduction Act of 1995.] 

I Agency Information-System Security 
Responsibilities Under the Act 

Under the Computer Security Act of 1987, all fed¬ 
eral agencies are required to identify computer 
systems containing sensitive information, and to 
develop security plans for identified systems. 35 
The act also requires mandatory periodic training 
in computer security for all federal employees and 
contractors who manage or use federal computer 
systems. The Computer Security Act gives final 


28 U.S. Congress, House of Representatives, Committee on Government Operations, Computer Security Act of1987 — Report to Accompa¬ 
ny H.R. 145. H. Rept. 100-153. Part II, 100th Cong., 1st sess., June 11,1987 (Washington, DC: U.S. Government Printing Office, 1987). p. 30. 

29 Ibid., p. 29. 

30 Ibid., p. 29. 

31 National Security Directive 42, op. cit., footnote 5. The National Security Council released an unclassified, partial text of NSD 42 to the 
Computer Professionals for Social Responsibility on April 1, 1992, in response to Freedom of Information Act (FOIA) requests made in 1990. 

32 Ibid., section 10. The Warner Amendment (Public Law 97-86) had exempted certain types of Defense Department procurements from the 
Brooks Act. 

33 NSD 42 (unclassified partial text), op. cit., footnote 31, sections 1-7. 

34 Security Policy Board Staff, “Creating a New Order in U.S. Security Policy,” Nov. 21, 1994, pp. 17-18. 

35 Public Law 100-235, section 6. 
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authority to NIST [then NBS] for developing 
government-wide standards and guidelines for 
unclassified, sensitive information, and for devel¬ 
oping government-wide training programs. 

In carrying out these responsibilities, NIST can 
draw upon the substantial expertise of NSA and 
other relevant agencies. Specifically, NIST is au¬ 
thorized to “coordinate closely with other agen¬ 
cies and offices,” including NSA, OTA, DOD, the 
Department of Energy, GAO, and OMB. 36 This 
coordination is aimed at “assuring] maximum 
use of all existing and planned programs, materi¬ 
als, studies, and reports relating to computer sys¬ 
tems security and privacy” and assuring that 
NIST’s computer security standards are “consis¬ 
tent and compatible with standards and proce¬ 
dures developed for the protection of information 
in federal computer systems which is authorized 
under criteria established by Executive order or an 
Act of Congress to be kept secret in the interest of 
national defense or foreign policy.” 37 Additional¬ 
ly, the Computer Security Act authorizes NIST to 
“draw upon computer system technical security 
guidelines developed by [NSA] to the extent that 
[NIST] determines that such guidelines are con¬ 
sistent with the requirements for protecting sensi¬ 
tive information in federal computer systems.” 38 
The act expected that “[t]he method for promul¬ 
gating federal computer system security standards 
and guidelines is the same as for non-security 
standards and guidelines.” 39 The intent of the act 
was that NSA not have the dominant role and to 
recognize the potential market impact of federal 
security standards: 

. . . [I]n carrying out its responsibilities to de¬ 
velop standards and guidelines for protecting 
sensitive information in federal computer sys¬ 


tems and to perform research, NBS [now NIST] 
is required to draw upon technical security 
guidelines developed by the NSA to the extent 
that NBS determines that NSA’s guidelines are 
consistent with the requirements of civil agen¬ 
cies. The purpose of this language is to prevent 
unnecessary duplication and promote the high¬ 
est degree of cooperation between these two 
agencies. NBS will treat NSA technical security 
guidelines as advisory, however, and, in cases 
where civil agency needs will best be served by 
standards that are not consistent with NSA 
guidelines, NBS may develop standards that 
best satisfy the agencies’ needs. 

It is important to note the computer security 
standards and guidelines developed pursuant to 
H.R. 145 are intended to protect sensitive in¬ 
formation in Federal computer systems. Never¬ 
theless, these standards and guidelines will 
strongly influence security measures imple¬ 
mented in the private sector. For this reason, 
NBS should consider the effect of its standards 
on the ability of U.S. computer system manufac¬ 
turers to remain competitive in the international 
marketplace. 40 

In its report accompanying H.R. 145, the Com¬ 
mittee on Government Operations noted that: 

While the Committee was considering H.R. 
145, proposals were made to modify the bill to 
give NSA effective control over the computer 
standards program. The proposals would have 
charged NSA with the task of developing “tech¬ 
nical guidelines,” and forced NBS to use these 
guidelines in issuing standards. 

Since work on technical security standards 
represents virtually all of the research effort be¬ 
ing done today, NSA would take over virtually 
the entire computer standards from the National 


36 Ibid., section 3(b)(6). 

37 Ibid. 

38 Ibid. 

37 H. Rept. 100-153, Part I, op. cit., footnote 12, p. 26. According to NIST, security FIPS are issued in the same manner as for nonsecurity 
FIPS. Although the Escrowed Encryption Standard (EES) has classified references, it had the same promulgation method. (F. Lynn McNulty, 
Associate Director for Computer Security, NIST, personal communication, Mar. 21, 1995.) 

40 Ibid., p. 27. 


1141 Issue Update on Information Security and Privacy in Network Environments 


Bureau of Standards. By putting NSA in charge 
of developing technical security guidelines 
(software, hardware, communications), NBS 
would be left with the responsibility for only ad¬ 
ministrative and physical security measures— 
which have generally been done years ago. 
NBS, in effect, would on the surface be given the 
responsibility for the computer standards pro¬ 
gram with little to say about most of the pro¬ 
gram—the technical guidelines developed by 
NSA. 

This would jeopardize the entire Federal 
standards program. The development of stan¬ 
dards requires interaction with many segments 
of our society, i.e., government agencies, com¬ 
puter and communications industry, interna¬ 
tional organizations, etc. NBS has performed 
this kind of activity very well over the last 22 
years [since enactment of the Brooks Act of 
1965]. NSA, on the other hand, is unfamiliar 
with it. Further, NSA’s products may not be use¬ 
ful to civilian agencies and, in that case, NBS 
would have no alternative but to issue standards 
based on these products or issue no standards at 
all. 41 

The Committee on Government Operations also 
noted the concerns of industry and the research 
community regarding the effects of export con¬ 
trols and NSA involvement in private sector acti¬ 
vities, including restraint of innovation in 
cryptography resulting from reduced incentives 
for the private sector to invest in independent re¬ 
search, development, and production of products 
incorporating cryptography. 42 

The Computer Security Act of 1987 estab¬ 
lished a Computer System Security and Privacy 


Advisory Board (CSSPAB) within the Commerce 
Department: 

The chief purpose of the Board is to assure 
that NBS receives qualified input from those 
likely to be affected by its standards and guide¬ 
lines, both in government and the private sector. 
Specifically, the duties of the Board are to iden¬ 
tify emerging managerial, technical, adminis¬ 
trative and physical safeguard issues relative to 
computer systems security and privacy and to 
advise the NBS and the Secretary of Commerce 
on security and privacy issues pertaining to fed¬ 
eral computer systems. 43 

The Chair of the CSSPAB is appointed by the Sec¬ 
retary of Commerce. The Board is required to re¬ 
port its findings relating to computer systems 
security and privacy to the Secretary of Com¬ 
merce, the OMB Director, the NSA Director, the 
House Committee on Government Operations, 
and the Senate Committee on Governmental Af¬ 
fairs. 44 

I Implementation Issues 

Implementation of the Computer Security Act has 
been controversial, particularly with respect to the 
roles of NIST and NSA in standards development. 
The two agencies developed a Memorandum of 
Understanding in 1989 to clarify the working rela¬ 
tionship, but this MOU has been controversial as 
well, because of concerns in Congress and else¬ 
where that its provisions cede NSA much more 
authority than the act had granted or envisioned 45 
Chapter 4 of the 1994 OTA report examined these 
implementation issues in depth. It concluded that 
clear policy guidance and congressional oversight 


41 H. Rept. 100-153, Part II, op. cit., footnote 28, pp. 25-26. 

4 - Ibid., pp. 22-25, 30-35. In 1986, NSA had announced a program to develop tamper proof cryptographic modules that qualified commu- 
nications manufacturers could embed in their products. NSA’s development of these embeddable modules was part of NSA’s Development 
Center for Embedded COMSEC Products. (NSA press release for Development Center for Embedded COMSEC Products, Jan. 10, 1986.) 

43 H. Rept. 100-153, Part I, op. cit., footnote 12, pp. 27-28. 

44 Public Law 100-235, section 3. 

45 The manner in which NIST and NSA planned to execute their functions under the Computer Security Act of 1987, as evidenced by the 
MOU, was the subject of hearings in 1989. See U.S. Congress, House of Representatives, Subcommittee on Legislation and National Security, 
Committee on Government Operations, Military and Civilian Control of Computer Security Issues, 101st Cong., 1st sess., May 4,1989 (Wash¬ 
ington, DC: U.S. Government Printing Office, 1989). The NIST-NS A working relationship has subsequently been raised as an issue, with regard 
to the EES and the DSS. See OTA, op. cit., footnote 1, ch. 4 and app. C. 
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will be needed if NIST/NSA processes and out¬ 
comes are to reflect a different balance of national 
security and other objectives, or more openness, 
than have been evidenced since 1989. 

The Computer Security Act of 1987 requires all 
federal agencies to identify computer systems 
containing sensitive information, and to develop 
security plans for these systems. 46 The act also re¬ 
quires mandatory periodic Paining in computer 
security for all federal employees and contractors 
who manage, use, or operate federal computer 
systems. In its workshops and discussions with 
federal employees and knowledgeable outside ob¬ 
servers, OTA found that these provisions of the 
Computer Security Act are viewed as generally 
adequate as written, but that their implementation 
can be problematic. 47 

During the course of the assessment and fol- 
low-on work, OTA found strong sentiment that 
agencies follow the rules set forth by the Comput¬ 
er Security Act, but not necessarily the full intent 
of the act. In practice, there are both insufficient 
incentives for compliance and insufficient sanc¬ 
tions for noncompliance with the spirit of the act. 
For example, though agencies do develop the re¬ 
quired security plans, the act does not require 
agencies to review them periodically or update 
them as technologies or circumstances change. 
One result of this is that “[sjecurity of systems 
tends to atrophy over time unless there is a stimu¬ 
lus to remind agencies of its importance.” 48 
Another result is that agencies may not treat secu¬ 


rity as an integral component when new systems 
are being designed and developed. 

Ongoing NIST activities in support of informa¬ 
tion security and privacy are conducted by NIST’s 
Computer Systems Laboratory. In the 1994 re¬ 
port, OTA noted that NIST’s funding for these se¬ 
curity functions ($4.5 million in appropriated 
funds for FY 1995) has chronically been low, giv¬ 
en NIST’s responsibilities under the Computer 
Security Act. “Reimbursable” funds received 
from other agencies (mainly DOD) have been sub¬ 
stantial ($2.0 million in FY 1995) compared with 
appropriated funds for security-related activities. 
Since FY 1990, they have represented some 30 to 
40 percent of the total funding for computer-secu¬ 
rity activities and staff at CSL. This is a large frac¬ 
tion of what has been a relatively small budget 
(about $6.5 million total in FY 1995). 

Some of the possible measures to improve im¬ 
plementation were mentioned during OTA staff 
interviews and workshops circa 1993-94 includ¬ 
ing the following: increasing resources for OMB 
to coordinate and oversee agency security plans 
and training; increasing resources for NIST and/or 
other agencies to advise and review agency securi¬ 
ty plans and training; setting aside part of agency 
budgets for information security (to be used for 
risk assessment, training, development, etc.); and/ 
or rating agencies according to the adequacy and 
effectiveness of their information-security poli¬ 
cies and plans and withholding funds until perfor¬ 
mance meets predetermined accepted levels. 


46 Public Law 100-235, section 6. 

47 Some of the possible measures to improve implementation that were suggested during these discussions were: increasing resources for 
OMB to coordinate and oversee agency security plans and training; increasing resources for NIST and/or other agencies to advise and review 
agency security plans and training; setting aside part of agency budgets for information security (to be used for risk assessment, training, devel¬ 
opment, and so forth); and/or rating agencies according to the adequacy and effectiveness of their information-security policies and plans and 
withholding funds until performance meets predetermined accepted levels. (Discussions in OTA workshops and interviews, 1993-94.) 

48 Office of Management and Budget (in conjunction with NIST and NS A), “Observations of Agency Computer Security Practices and 
Implementation of OMB Bulletin No. 90-08: Guidance for Preparation of Security Plans for Federal Computer Systems That Contain Sensitive 
Information,” February 1993, p. 11. 
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T he United States has two regulatory re¬ 
gimes for exports, depending on whether 
the item to be exported is military in na¬ 
ture, or is “dual-use,” having both civilian 
and military uses. These regimes are administered 
by the State Department and the Commerce De¬ 
partment, respectively. Both regimes provide ex¬ 
port controls on selected goods or technologies for 
reasons of national security or foreign policy. Li¬ 
censes are required to export products, services, or 
scientific and technical data 1 originating in the 
United States, or to re-export these from another 
country. 


Licensing requirements vary according to the 
nature of the item to be exported, the end use, the 
end user, and, in some cases, the intended destina¬ 
tion. For many items that are under Commerce ju¬ 
risdiction, no specific approval is required and a 
“general license” applies (e.g., when the item in 
question is not military or dual-use and/or is wide¬ 
ly available from foreign sources). In other cases, 
an export license must be applied for from either 
the State Department or the Commerce Depart¬ 
ment, depending on the nature of the item. In 
general, the State Department’s licensing require¬ 
ments are more stringent and broader in scope. 2 


1 Both the Export Administration Act (50 U.S.C. App. 2401-2420) and the Arms Export Control Act (22 U.S.C. 2751-2794) provide author- 
ity to control the dissemination to foreign nationals (export) of scientific and technical data related to items requiring export licenses under the 
regulations implementing these acts. “Scientific and technical data” can include plans, design specifications, or other information that describes 
how to produce an item. See U.S. Congress, Office of Technology Assessment, Information Security and Privacy in Network Environments, 
OTA-TCT-606 (Washington, DC; U.S. Government Printing Office, September 1994), pp. 150-160. 

Other statutory authorities for national security controls on scientific and technical data are found in the Restricted Data or “bom classified” 
provisions of the Atomic Energy Act of 1946 (60 Stat. 755) and the Atomic Energy Act of 1954 (68 Stat. 919,42 U.S.C. 2011-2296), and in the 
Invention Secrecy Act of 1951 (35 U.S.C. 181-188), which allows for patent secrecy orders and withholding of patents on national security 
grounds. NS A has obtained patent secrecy orders on patent applications for cryptographic equipment and algorithms under authority of the 
Invention Secrecy Act. 

2 For another comparison of the two export-control regimes, see U.S. General Accounting Office, Export Controls: Issues in Removing 
Militarily Sensitive Items from the Munitions List, GAO/NSIAD-93-67 (Washington, DC: U.S. Government Printing Office, March 1993), esp. 
pp. 10-13. 
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The material in this appendix is taken from pages 
150-160 of the 1994 OTA report, updated where 
appropriate. Licensing terms differ between the 
agencies, as do time frames and procedures for li¬ 
censing review, revocation, and appeal. 

STATE DEPARTMENT EXPORT 
CONTROLS ON CRYPTOGRAPHY 

The Arms Export Control Act and International 
Traffic in Arms Regulations (ITAR), 3 adminis¬ 
tered by the State Department, control export of 
items (including hardware, software, and techni¬ 
cal data) that are “inherently military in character” 
and, therefore, placed on the Munitions List. 4 Un¬ 
less otherwise indicated, items on the Munitions 
List are controlled to all destinations, meaning 
that “validated” licenses—requiring case-by-case 
review—are required for any exports (except to 
Canada, in some cases). The Munitions List is es¬ 
tablished by the State Department, in concurrence 
with the Defense Department; the State Depart¬ 
ment’s Office of Defense Trade Controls adminis¬ 
ters the ITAR and issues licenses for approved 
exports. The Defense Department provides tech¬ 
nical advice to the State Department when there 
are questions concerning license applications or 
commodity jurisdiction (i.e., whether State or 
Commerce regulations apply—see below). 

With certain exceptions, cryptography falls in 
“Category XIII—Auxiliary Military Equipment” 
of the Munitions List. Category XIII(b) covers 
“Information Security Systems and equipment, 
cryptographic devices, software and components 
specifically designed or modified therefore,” gen¬ 
erally including: 

1. cryptographic and key-management systems 
and associated equipment, subcomponents, 
and software capable of maintaining informa¬ 


tion or information-system secrecy/confiden¬ 
tiality; 

2. cryptographic and key-management systems 
and associated equipment, subcomponents, 
and software capable of generating spreading 
or hopping codes for spread-spectrum systems 
or equipment; 

3. cryptanalytic systems and associated equip¬ 
ment, subcomponents, and software; 

4. systems, equipment, subcomponents and soft¬ 
ware capable of providing multilevel security 
that exceeds class B2 of the National Security 
Agency’s (NSA’s) Trusted Computer System 
Evaluation Criteria, as well as software used 
for certification; 

5. ancillary equipment specifically designed or 
modified for these functions; and 

6. technical data and defense services related to 
the above. 5 

Several exceptions apply to item XIII(b)(l) 

above. These include the following subcategories 

of cryptographic hardware and software: 

a. those used to decrypt copy-protected software, 
provided that the decryption functions are not 
user-accessible; 

b. those used only in banking or money transac¬ 
tions (e.g., in ATM machines and point-of-sale 
terminals, or for encrypting interbanking trans¬ 
actions); 

c. those that use analog (not digital) techniques 
for cryptographic processing in certain applica¬ 
tions, including facsimile equipment, re¬ 
stricted-audience broadcast equipment, and 
civil television equipment; 

d. those used in personalized smart cards when 
the cryptography is of a type restricted for use 
only in applications exempted from Munitions 
List controls (e.g., in banking applications); 


3 22 C.F.R. 120-130. 

4 See Supplement 2 to Part 770 of the Export Administration Regulations. The Munitions List has 21 categories of items and related technol- 
ogies, such as artillery and projectiles (Category II) or toxicological and radiological agents and equipment (Category XIV). Category XIII(b) 
consists of “Information Security Systems and equipment, cryptographic devices, software, and components specifically modified therefore.” 

5 Ibid. See Category XIII(b)((l)-(5)) and XIII(k). For a review of controversy during the 1970s and early 1980s concerning control of cryp¬ 
tographic publication, see F. Weingarten, “Controlling Cryptographic Publication,” Computers & Security, vol. 2, 1983, pp. 41-48. 


1181 Issue Update on Information Security and Privacy in Network Environments 


e. those limited to access-control functions (e.g., 
for ATM machines, point-of-sale terminals, 
etc.) in order to protect passwords, personal 
identification numbers, and the like provided 
that they do not provide for encryption of other 
files or text; 

f. those limited to data authentication (e.g., calcu¬ 
lating a message authentication code) but not 
allowing general file encryption; 

g. those limited to receiving radio broadcast, pay 
television, or other consumer-type restricted 
audience broadcasts, where digital decryption 
is limited to the video, audio, or management 
functions and there are no digital encryption ca¬ 
pabilities; and 

h. those for software designed or modified to pro¬ 
tect against malicious computer damage from 
viruses, and so forth. 6 

Cryptographic hardware and software in these 
subcategories are excluded from the ITAR regime 
and fall under Commerce’s jurisdiction. Note, 
however, that these exclusions do not include 
hardware-based products for encrypting data or 
other files before transmission or storage, or user- 
accessible, digital encryption software for ensur¬ 
ing email confidentiality or read-protecting stored 
data or text files. These remain under State De¬ 
partment control. 

In September 1994, the State Department an¬ 
nounced an amendment to the regulations imple¬ 
menting section 38 of the Arms Export Control 
Act. 7 The new rule implements one of the reforms 
applicable to encryption products that were an¬ 
nounced on February 4,1994, by the State Depart¬ 


ment. 8 It established a new licensing procedure in 
the ITAR to permit U.S. encryption manufacturers 
to make multiple shipments of items covered by 
Category XIII(b)(l) of the Munitions List (see 
above) directly to end users in an approved coun¬ 
try, without obtaining individual licenses. Pre¬ 
viously, only those exports covered by a 
distribution arrangement could be shipped with¬ 
out an individual license; the new procedure per¬ 
mits direct distribution from manufacturers 
without foreign distributors. The procedures are 
similar - to existing distribution agreement proce¬ 
dures; exporters submit a proposed arrangement 
specifying items to be shipped, proposed end us¬ 
ers and uses, and destination countries. Upon ap¬ 
proval, exporters can ship the specified products 
directly to the end users in the approved countries, 
with a single license. 9 Among the other reforms 
announced in February 1994 but awaiting imple¬ 
mentation are special licensing procedures that 
would permit export of key-escrow encryption 
products to “most” end users. 10 

COMMERCE DEPARTMENT EXPORT 
CONTROLS ON CRYPTOGRAPHY 

The Export Administration Act (EAA) 11 and Ex¬ 
port Administration Regulations (EAR), 12 ad¬ 
ministered by the Commerce Department, are 
designed to control exports of “sensitive” or dual- 
use items, including software and scientific and 
technical data. Some items on the Commerce 
Control List (CCL) are controlled for national se¬ 
curity puiposes, to prevent them from reaching 
“proscribed” countries (usually in the former So- 


6 Munitions List, ibid. See XIII(b) (1) (i)-(ix). 

7 Department of State, Bureau of Political-Military Affairs, 22 CFR parts 123 and 124, Federal Register, vol. 59, No. 170, Sept. 2,1994, pp. 
45621-45623. 

8 Martha Harris, Deputy Assistant Secretary for Political-Military Affairs, U.S. Department of State. “Encryption—Export Control Re¬ 
form,’ - statement, Feb. 4, 1994. 

9 Federal Register, op. cit., footnote 7, p. 45621. 

10 Martha Harris, op. cit., footnote 8. 

11 At this writing, the export administration legislation is to be reauthorized. 

12 22 U.S.C. 2751-2794. 
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viet bloc); others are controlled for various foreign 
policy objectives. 13 

The Bureau of Export Administration adminis¬ 
ters controls on dual-use items. The Bureau of Ex¬ 
port Administration’s Office of Strategic Trade 
and Foreign Policy Controls 14 is responsible for 
making licensing determinations, coordinating 
with other responsible agencies as necessary, and 
maintaining the Commerce Control List for cryp¬ 
tographic products. 15 

Cryptography falls under Section II (“Informa¬ 
tion Security”) of the CCL. 16 This category 
includes information-security “equipment, as¬ 
semblies and components” that: 

1. are designed or modified to use digital cryptog¬ 
raphy for information security; 

2. are designed or modified to use cryptanalytic 
functions; 

3. are designed or modified to use analog cryptog¬ 
raphy, except for some low-speed, fixed band 
scrambling or frequency inversion, or in fac¬ 
simile equipment, restricted audience broad¬ 
cast equipment or civil television equipment 
(see item c above); 

4. are designed to suppress compromising emana¬ 
tions of information-bearing signals, except for 
suppression of emanations for health or safety 
reasons; 

5. are designed or modified to use cryptography to 
generate the spreading code for spread-spec¬ 
trum systems or the hopping code for frequency 
agility systems; or 


6. are designed or modified to exceed class B2 of 
the Trusted Computer System Evaluation Cri¬ 
teria (see item 4 in the State Department list 
above); plus those that 

7. are communications cable systems with intru¬ 
sion-detection capabilities. 

Equipment for the test, inspection, and production 
(including evaluation and validation equipment) 
of equipment or functions in this category are in¬ 
cluded, as are related software and technology. 

OVERLAP BETWEEN 
CONTROL REGIMES 

The “overlap” between the State Department and 
Commerce Department export-control regimes is 
particularly complex for cryptography (note the 
overlap between the Munitions List items and the 
CCL items shown above, even with the excep¬ 
tions). Basically, the Commerce Department li¬ 
censes only those Section II items that are either 
excepted from State Department control, are not 
controlled, or are eligible for licensing under an 
advisory note, plus anti virus software (see item h 
in the section on State Department controls 
above). 17 The cryptographic items exempted 
from control under advisory note 1 are: personal¬ 
ized smart cards as described in item d above; 
equipment for fixed data compression or coding 
techniques, or for use in applications described in 
item g above; portable, commercial civil cellular 
phones containing encryption, when accompany- 


13 See GAO, op. cit., footnote 2, pp. 10-12. 

14 The functions of the Office of Export Licensing and the Office of Technology and Policy Analysis were merged and shifted after a reorga- 
nization of the Bureau of Export Administration in late 1994-early 1995. (Maurice Cook, Bureau of Export Administration, Economic Analysis 
Division, personal communication, Mar. 17, 1995.) 

15 Joseph Young, Office of Strategic Trade and Foreign Policy Controls, Bureau of Export Administration, personal communication, Mar. 
23, 1995. 

16 See Supplement 1 to Part 799.1 of the Export Administration Regulations, sections A (equipment, assemblies and components), B (test, 
inspection, and production equipment), D (software), and E (technology). 

17 Ibid., p. CCL123 (notes). The advisory notes specify items that can be licensed by Commerce under one or more administrative excep¬ 
tions. 
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ing their users; and software as described in item a 
above. 18 Other items, such as cellular phone sys¬ 
tems for which message traffic encryption is not 
possible or items for civilian use in banking, ac¬ 
cess control, and authentication as described un¬ 
der items b), e), or f) above, are covered by 
advisory notes 3 through 5. These advisory notes 
state that these items are likely to be licensed by 
Commerce, as administrative exceptions, for ex¬ 
port to acceptable end users. 19 

At present, software and hardware for robust, 
user-controlled encryption remains on the Muni¬ 
tions List under State Department control, unless 
State grants jurisdiction to Commerce. 20 This has 
become increasingly controversial, especially for 
the information technology and software indus¬ 
tries. According to the U.S. General Accounting 
Office’s (GAO’s) 1993 report: 

NSA performs the technical review that deter¬ 
mines, for national security reasons, (1) if a product 
with encryption capabilities is a munitions item or a 
Commerce List item and (2) which munitions items 
with encryption capabilities may be exported. The 
Department of State examines the NSA determina¬ 
tion for consistency with prior NSA determinations 
and may add export restrictions for foreign policy 
reasons—e.g., all exports to certain countries may 
be banned for a time period. 

... [T]he detailed criteria for these decisions are 
generally classified. However, vendors exporting 
these items can leam some of the general criteria 
through prior export approvals or denials they have 
received. NSA representatives also advise compa¬ 
nies regarding whether products they are planning 
would likely be munitions items and whether they 
would be exportable, according to State Depart¬ 
ment representatives. 21 


At the end of COCOM in 1994, the Clinton Ad¬ 
ministration liberalized the policy for some ex¬ 
ports of computer and telecommunications 
products to Russia, Eastern Europe, and China. 
However, controls were maintained on cryptogra¬ 
phy because: 

The President has determined that vital U.S. 
national security and law enforcement interests 
compel maintaining appropriate control of encryp¬ 
tion. 22 

In 1992, there had been limited relaxation of ex¬ 
port controls for mass-marketed software with 
encryption capabilities. NSA and the State De¬ 
partment relaxed and streamlined export controls 
for mass-market software with moderate encryp¬ 
tion capabilities, but not including software im¬ 
plementing the Data Encryption Standard (DES) 
or computer hardware containing encryption al¬ 
gorithms. 23 Also, since July 1992, there has been 
expedited review of software using one of two al¬ 
gorithms developed by RSA Data Security, Inc. 
These algorithms, called RC2 and RC4, are said to 
be significantly stronger than those previously al¬ 
lowed for export, but are limited to a 40-bit key 
length and are said to be weaker than the “DES- 
strength” programs that can be marketed in the 
United States and that are available overseas. 

U.S. software producers still face the ITAR re¬ 
strictions (with the new, expedited-distribution 
rule noted above) for exports of software with 
strong encryption. 24 Software or hardware prod¬ 
ucts using the DES for message encryption (as op¬ 
posed to message authentication) are on the 
Munitions List and are generally nonexportable to 
foreign commercial users, except foreign subsid¬ 
iaries of U.S. firms and some financial institutions 


18 Ibid., pp. CCL123-126. Software required for or providing these functions is also excepted. 

19 Ibid., Advisory Notes 1-5. 

20 GAO, op. cit., footnote 2, pp. 24-28. 

21 Ibid., p. 25. 

22 Martha Harris, op. cit., footnote 8. 

23 Ibid. 

24 “Strong” encryption in this context refers to systems on a par with the DES or with the RSA system with a 1,024-bit modulus. 
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(for use in electronic funds transfers). Products 
that use the DES and other algorithms for pur¬ 
poses other than message encryption (e.g., for au¬ 
thentication) can be exported on the Commerce 
Control List, however. 25 

In the 103d Congress, legislation intended to 
streamline controls and ease restrictions on mass- 
market computer software, hardware, and tech¬ 
nology, including certain encryption software, 


had been introduced. No export legislation was 
enacted, however, and the last reported version of 
the House legislation did not include these provi¬ 
sions. 26 In the 104th Congress, omnibus export 
administration legislation for 1995 has been 
introduced in the House (H.R. 361). At this writ¬ 
ing, it does not have special provisions for cryp¬ 
tography. 


25 GAO, op. cit., footnote 2. p. 26. For discussion of industry and government views. OTA, op. cit., footnote 1. pp. 154-160. 

26 See U.S. Congress, House of Representatives, Omnibus Export Administration Act of1994, H. Rept. 103-531,103d Cong., 2d sess., Parts 
1 (Committee on Foreign Affairs, May 25, 1994), 2 (Permanent Select Committee on Intelligence, June 16, 1994), 3 (Committee on Ways and 
Means, June 7, 1994), and 4 (Committee on Armed Services, June 17, 1994) (Washington, DC, U.S. Government Printing Office, 1994); and 
H.R. 4663, “Omnibus Export Administration Act of 1994,” June 28, 1994. 



Appendix D: 
Summary of Issues 
and Options from 
the 1994 OTA Report 


P art of the motivation for the OTA report In¬ 
formation Security and Privacy in Net¬ 
work Environments was the recognition 
that we are in transition to a society that is 
becoming critically dependent on electronic in¬ 
formation and network connectivity. This is ex¬ 
emplified by the explosive growth of the Internet 
and sources of online information and entertain¬ 
ment. 1 

The need for congressional attention to safe¬ 
guarding information has been reinforced in the 
months since the report was issued in September 
1994. The use of information networks for busi¬ 
ness has continued to expand, and ventures to 


bring electronic commerce and “electronic cash” 
into homes and offices are materializing rapidly. 2 
Government agencies have continued to expand 
both the scale and scope of their network connecti¬ 
vities. Information technologies and networks are 
featured even more prominently in plans to make 
government more efficient, effective, and respon¬ 
sive. 3 

Concerns for the security and privacy of net¬ 
worked information remain. In its 1994 report, 
OTA found that the fast-changing and competitive 
marketplace that produced the Internet and a 
strong networking and software industry in the 


1 For example, the number of Internet users has been more than doubling each year; some 30 million people worldwide can exchange mes- 
sages over the Internet. “Browsing” and “chatting” online at home and in the office is increasingly popular—see, e.g., Molly O’Neill, “The Lure 
and Addiction of Life On Line,” The New York Times, Mar. 8, 1995, pp. Cl, C6. 

2 See, e.g., Randy Barrett, “Hauling In the Network—Behind the World’s Digital Cash Curve,” Washington Technology, Oct. 27,1994, p. 18; 
Neil Munro, “Branch Banks Go Way of the Drive-In,” Washington Technology, Feb. 23, 1995, pp. 1,48; Amy Cortese et al., “Cashing In on 
Cyberspace: A Rush of Software Development to Create an Electronic Marketplace,” Business Week, Feb. 27, 1995, pp. 78-86; Bob Metcalfe, 
“Internet Digital Cash—Don’t Leave Your Home Page Without It ,” InfoWorld, Mar. 13,1995, p. 55; “Netscape Signs Up 19 Users for Its System 
of Internet Security,” The Wall Street Journal, Mar. 20, 1995, p. B3; and Saul Hansell, “VISA Will Put a Microchip in New Cards—Product Is 
Designed for Small Purchases,” The New York Times, Mar. 21, 1995, p. D3. 

3 See, e.g., Neil Munro, “Feds May Get New Infotech Executive,” Washington Technology, Feb. 23, 1995, pp. 1, 49; Charles A Bowsher, 
Comptroller General of the United States, “Government Reform: Using Reengineering and Technology to Improve Government Perfor¬ 
mance,” GAO/T-OCG-95-2, testimony before the Committee on Governmental Affairs, U.S. Senate, Feb. 2,1995; and Elena Varon, “Reinvent¬ 
ing Is Old Hat for New Chairman,” Federal Computer Week, Feb. 20, 1995, pp. 22, 27. 
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United States has not consistently produced prod¬ 
ucts equipped with affordable, user-friendly safe¬ 
guards. Many individual products and techniques 
are available to adequately safeguard specific in¬ 
formation networks, if the user knows what to pur¬ 
chase and can afford and correctly use the product. 
Nevertheless, better and more affordable products 
are needed. In particular, OTA found a need for 
products that integrate security features with oth¬ 
er functions for use in electronic commerce, elec¬ 
tronic mail, or other applications. 

OTA found that more study is needed to fully un¬ 
derstand vendors’ responsibilities with respect to 
software and hardware product quality and liabil¬ 
ity. OTA also found that more study is also needed 
on the effects of export controls on the domestic 
and global markets for information safeguards, 
and on the ability of safeguard developers and 
vendors to produce more affordable, integrated 
products. OTA concluded that broader efforts to 
safeguard networked information will be frus¬ 
trated unless cryptography-policy issues are re¬ 
solved. 

OTA found that the single most important step 
toward implementing proper safeguards for net¬ 
worked information in a federal agency or other 
organization is for top management to define the 
organization’s overall objectives, define an orga¬ 
nizational security policy to reflect those objec¬ 
tives, and implement that policy. Only top 
management can consolidate the consensus and 
apply the resources necessary to effectively pro¬ 
tect networked information. For the federal gov¬ 
ernment, this requires guidance from the Office of 
Management and Budget (OMB) (e.g., in OMB 
Circular A-130), commitment from top agency 
management, and oversight by Congress. The 
1994 OTA report found that in practice, there have 
historically been both insufficient incentives for 
compliance, as well as insufficient sanctions for 
noncompliance, with the spirit of the Computer 
Security Act. 


During the course of the OTA assessment 
(1993-94), there was widespread controversy con¬ 
cerning the Clinton Administration’s escrowed- 
encryption initiative. The significance of this 
initiative, in concert with other federal cryptogra¬ 
phy policies, resulted in an increased focus in the 
report on the processes that the government uses 
to regulate cryptography and to develop federal 
information processing standards (FIPS) based on 
cryptography. 

The 1994 report focused on policy issues in three 
areas: 1) cryptography policy, including federal 
information processing standards and export con¬ 
trols; 2) guidance on safeguarding unclassified in¬ 
formation in federal agencies; and 3) legal issues 
and information security, including electronic 
commerce, privacy, and intellectual property. The 
following sections present the issues and options 
from that report. 

NATIONAL CRYPTOGRAPHY POLICY 4 

The 1994 OTA report concluded that Congress 
has vital strategic roles in cryptography policy 
and, more generally, in safeguarding information 
and protecting personal privacy in a networked so¬ 
ciety. Because cryptography has become a 
technology of broad application, decisions about 
cryptography policy have increasingly broad ef¬ 
fects on society. Federal standards (e.g., the feder¬ 
al information processing standards, or the FIPS) 
and export controls have substantial significance 
for the development and use of these technologies. 

I Congressional Review and 
Open Processes 

In 1993, having recognized the importance of 
cryptography and the policies that govern the de¬ 
velopment, dissemination, and use of the technol¬ 
ogy, Congress asked the National Research 
Council (NRC) to conduct a major study that 
would support a broad review of cryptography and 


4 See Information Security and Privacy in Network Environments, OTA-TCT-606 (Washington, DC; U.S. Government Printing Office, Sep¬ 
tember 1994), pp. 8-18. 
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its deployment. 5 An important outcome of this re¬ 
view of national cryptography policy would be the 
development of more open processes to determine 
how cryptography will be deployed throughout 
society. Cryptography deployment includes de¬ 
velopment of the public-key infrastructures and 
certification authorities that will support electron¬ 
ic delivery of government services, copyright 
management, and digital commerce. 

The results of the NRC study are expected to be 
available in 1996. But, given the speed with which 
the Clinton Administration is acting to deploy es¬ 
crowed encryption within the government, OTA 
concluded that information to support a congres¬ 
sional policy review of cryptography is out of 
phase with implementation. Therefore, OTA 
noted that: 

OPTION: Congress could consider placing a 
hold on further deployment of key-escrow encryp¬ 
tion, pending a congressional policy review. 

More open processes would build trust and con¬ 
fidence in government operations and leadership. 
More openness would allow diverse stakeholders 
to understand how their views and concerns were 
being balanced with those of others, in establish¬ 
ing an equitable deployment of these technolo¬ 
gies, even when some of the specifics of the 
technology remain classified. (See also the policy 
section below on safeguarding information in fed¬ 
eral agencies.) More open processes would also 
allow for public consensus-building, providing 
better information for use in congressional over¬ 
sight of agency activities. Toward these ends, 
OTA noted that: 

OPTION: Congress could address the extent to 
which the current working relationship between 
NIST and NSA will be a satisfactory part of this 
open process, or the extent to which the current 
arrangements should be reevaluated and revised. 

Another important outcome of a broad policy re¬ 
view would be a clarification of national informa¬ 
tion-policy principles in the face of technological 
change: 


OPTION: Congress could state its policy as to 
when the impacts of a technology (like cryptogra¬ 
phy) are so powerful and pervasive that legisla¬ 
tion is needed to provide sufficient public visibility 
and accoun tability for government actions. 

During the assessment, OTA found that many of 
the persistent concerns surrounding the Escrowed 
Encryption Standard, and the Clinton Administra¬ 
tion’s escrowed-encryption initiative generally, 
focused on whether key-escrow encryption will 
become mandatory for government agencies or 
the private sector, if nonescrowed encryption will 
be banned, and/or if these actions could be taken 
without legislation. Other concerns still focus on 
whether or not alternative forms of encryption 
would be available that would allow private indi¬ 
viduals and organizations the option of depositing 
keys (or not) with one or more third-party trust¬ 
ees—at their discretion. The National Research 
Council study should be valuable in helping Con¬ 
gress to understand the broad range of technical 
and institutional alternatives available for various 
types of trusteeships for cryptographic keys, “dig¬ 
ital powers of attorney,” and the like. However, if 
implementation of the EES and related technolo¬ 
gies continues at the current pace, OTA noted that 
key-escrow encryption may already be embedded 
in information systems before Congress can act on 
the NRC report. 

I Export Controls on Cryptography 

As part of a broad national cryptography policy, 
OTA noted that Congress may wish to periodical¬ 
ly examine export controls on cryptography, to en¬ 
sure that these continue to reflect an appropriate 
balance between the needs of signals intelligence 
and law enforcement and the needs of the public 
and business communities. This examination 
would take into account changes in foreign capa¬ 
bilities and foreign availability of cryptographic 
technologies. 


5 For information about the NRC study, contact Herb Lin at the National Research Council (crypto@nas.edu). 
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Information from an executive branch study of 
the encryption market and export controls that 
was promised by Vice President Gore should pro¬ 
vide some near-term information. 6 At this writ¬ 
ing, the Commerce Department and the National 
Security Agency (NSA) arc assessing the eco¬ 
nomic impact of U.S. export controls on the U.S. 
computer software industry; as part of this study, 
NSA is determining the foreign availability of en¬ 
cryption products. 7 The study is scheduled to be 
delivered to National Security Council (NSC) de¬ 
puties by July 1, 1995. It is anticipated that there 
will be both unclassified and classified portions of 
the study; there may be some public release of the 
unclassified material. 8 

OTA noted that the scope and methodology of 
the export-control studies that Congress might 
wish to use in the future may differ from those 
used in the executive branch study. Therefore: 

OPTION: Congress might wish to assess the va¬ 
lidity and effectiveness of the Clinton Administra¬ 
tion’s studies of export con trols on cryptography 
by conducting oversight hearings, by undertaking 
a staff analysis, or by requesting a study from the 
Congressional Budget Office. 

I Congressional Responses to 
Escrowed-Encryption Initiatives 

OTA also recognized that Congress also has a 
more near-term role to play in determining the 
extent to which—and how—the Escrowed En¬ 
cryption Standard (EES) and other escrowed-en¬ 
cryption systems will be deployed in the United 
States. These actions can be taken within a long¬ 
term, strategic framework. Congressional over¬ 
sight of the effectiveness of policy measures and 
controls can allow Congress to revisit these issues 
as needed, or as the consequences of previous de¬ 
cisions become more apparent. 

The Escrowed Encryption Standard (Clipper) 
was issued as a voluntary FIPS; use of the EES by 


the private sector is also voluntary. The Clinton 
Administration has stated that it has no plans to 
make escrowed encryption mandatory, or to ban 
other forms of encryption. But, absent legislation, 
these intentions are not binding for future admin¬ 
istrations and also leave open the question of what 
will happen if the EES and related technologies do 
not prove acceptable to the private sector. More¬ 
over, the executive branch may soon be using the 
EES and/or related escrowed-encryption technol¬ 
ogies to safeguard—among other things—large 
volumes of private information about individuals 
(e.g., taxpayer data and health care information). 

For these reasons, OTA concluded that the EES 
and other key-escrowing initiatives are by no 
means only an executive branch concern. The 
EES and any subsequent escrowed-encryption 
standards (e.g., for data communications in com¬ 
puter networks, or for file encryption) also war¬ 
rant congressional attention because of the public 
funds that will be spent in deploying them. More¬ 
over, negative public perceptions of the EES and 
the processes by which encryption standards are 
developed and deployed may erode public confi¬ 
dence and trust in government and, consequently, 
the effectiveness of federal leadership in promot¬ 
ing responsible safeguard use. 

In responding to current escrowed-encryption 
initiatives like the EES, and in determining the ex¬ 
tent to which appropriated funds should be used in 
implementing key-escrow encryption and related 
technologies, OTA noted that: 

OPTION: Congress could address the appropri¬ 
ate locations of the key-escrow agents, particular¬ 
ly f or federal agencies, before additional 
investments are made in staff and facilities for 
them. Public acceptance of key-escrow encryption 
might be improved—but not assured—by an es¬ 
crowing system that used separation of powers to 
reduce perceptions of the potential for misuse. 


6 Vice President A1 Gore, letter to Representative Maria Cantwell. July 20, 1994. See OTA. op. cit., footnote 4, pp. 11-13. 

7 Maurice Cook, Bureau of Export Administration, Economic Analysis Division, personal communication. Mar. 7. 1995. 

8 Bill Clements, National Security Council, personal communication. Mar. 21, 1995. 
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With respect to current escrowed-encryption ini¬ 
tiatives like the EES, as well as any subsequent 
key-escrow encryption initiatives (e.g., for data 
communications or file encryption), and in deter¬ 
mining the extent to which appropriated funds 
should be used in implementing key-escrow en¬ 
cryption and related technologies, OTA noted 
that: 

OPTION: Congress could address the issue of 
criminal penalties for misuse and unauthorized 
disclosure of escrowed key componen ts. 

OPTION: Congress could consider allowing 
damages to be awarded for individuals or orga¬ 
nizations who were harmed by misuse or unautho¬ 
rized disclosure of escrowed key componen ts. 

SAFEGUARDING INFORMATION 
IN FEDERAL AGENCIES 9 

Congress has an even more direct role in establish¬ 
ing the policy guidance within which federal 
agencies safeguard information, and in oversight 
of agency and OMB measures to implement in¬ 
formation security and privacy requirements. The 
Office of Management and Budget is responsible 
for developing and implementing government¬ 
wide policies for information resource manage¬ 
ment; for overseeing the development and 
promoting the use of government information- 
management principles, standards, and guide¬ 
lines; and for evaluating the adequacy and 
efficiency of agency information-management 
practices. During the assessment, OTA found that 
information-security managers in federal agen¬ 
cies must compete for resources and support to 
properly implement needed safeguards. For their 
efforts to succeed, both OMB and top agency 
management must fully support investments in 
cost-effective safeguards. Given the expected in¬ 
crease in interagency sharing of data, interagency 
coordination of privacy and security policies is 


also necessary to ensure uniformly adequate 
protection. 

I Effectiveness of OMB Guidance 

The Paperwork Reduction Act of 1995 was signed 
by President Clinton on May 22, 1995. Both the 
House (H.R. 830) and Senate (S. 244) versions of 
the bill reaffirmed OMB’s authorities under the 
Computer Security Act for safeguarding unclassi¬ 
fied information. The conference bill 10 containing 
these provisions passed in both Houses on April 6, 
1995 (see chapter 4 of this background paper for 
discussion). 

Appendix III (“Security of Federal Automated 
Information Systems”) of the 1985 version of 
OMB Circular A-130 set forth OMB’s govern¬ 
ment-wide policy guidance for information secu¬ 
rity. At this writing, a new, proposed revision of 
Appendix III has just been issued. The proposed 
revision is intended to lead to improved federal in- 
formation-security practices and to make fulfill¬ 
ment of Computer Security Act and Privacy Act 
requirements more effective generally, as well as 
with respect to data sharing and secondary uses. 

The new, proposed revision of Appendix III 
(“Security of Federal Automated Information”) 
will be key to assessing the prospect for improved 
federal information security practices. The pro¬ 
posed revision was presented for comment at the 
end of March 1995. According to OMB, the pro¬ 
posed new government-wide guidance: 

... is intended to guide agencies in securing in¬ 
formation as they increasingly rely on an open and 
interconnected National Information Infrastruc¬ 
ture. It stresses management controls such as indi¬ 
vidual responsibility, awareness and training, and 
accountability, rather than technical con¬ 
trols. . . The proposal would also better integrate 
security into program and mission goals, reduce the 
need for centralized reporting of paper security 
plans, emphasize the management of risk rather 


9 See OTA. op. cit., footnote 4. pp. 18-20. 

10 See U.S. Congress, House of Representatives, “Paperwork Reduction Act of 1995—Conference Report to Accompany S.244,” H.Rpt. 
104-99, Apr. 3, 1995. These provisions are found in 44U.S.C. section 3504. 
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than its measurement, and revise government-wide 
security responsibilities to be consistent with the 
Computer Security Act . 11 

See chapter 4 of this background paper for discus¬ 
sion of the proposed revision to Appendix III. The 
issues and options presented below are in the con¬ 
text of the 1994 report and the 1985 Appendix III. 
However, OTA expects that congressional over¬ 
sight and analysis as indicated below will remain 
useful for understanding OMB's new guidance 
and assessing its potential effectiveness. 

Because the revised Appendix III had not been 
issued by the time Information Security and Pri¬ 
vacy in Network Environments was completed in 
1994, the OTA report was unable to assess the re¬ 
vision’s potential for improving information secu¬ 
rity in federal agencies, for holding agency 
managers accountable for security, or for ensuring 
uniform protection in light of data sharing and 
secondary uses. OTA noted that, after the revised 
Appendix III of OMB Circular A-130 is issued: 

OPTION: Congress could assess the effective¬ 
ness of the OMB's revised guidelines, including 
improvements in implementing the Computer Se¬ 
curity Act’s provisions regarding agency security 
plans and training, in order to determine whether 
additional statutory requirements or oversight 
measures are needed. 

This might be accomplished by conducting 
oversight healings, undertaking a staff analysis, 
and/or requesting a study from the General Ac¬ 
counting Office (GAO). However, the effects of 
OMB’s revised guidance may not be apparent for 
some time after the revised Appendix III is issued. 

Therefore, a few years may pass before GAO is 
able to report government-wide findings that 
would be the basis for determining the need for 
further revision or legislation. In the interim: 

OPTION: Congress could gain additional in¬ 
sight through hearings to gauge the reaction of 
agencies, as well as privacy and security experts 


from outside governmen t, to OMB’s revised guide¬ 
lines. 

Oversight of this sort might be especially valu¬ 
able for agencies, such as the Internal Revenue 
Service, that are developing major new informa¬ 
tion systems. In the course of its oversight and 
when considering the direction of any new legisla¬ 
tion, OTA noted that: 

OPTION: Congress could ensure that agencies 
include explicit provisions for safeguarding in¬ 
formation assets in any information-technology 
planning documents. 

OPTION: Congress could ensure that agencies 
budget sufficient resources to safeguard informa¬ 
tion assets, whether as a percentage of informa¬ 
tion-technology modernization and/or operating 
budgets, or otherwise. 

OPTION: Congress could ensure that the De¬ 
partment of Commerce assigns sufficient re¬ 
sources to the National Institu te of Standards and 
Technology (NIST) to support its Computer Secu¬ 
rity Act responsibilities, as well as NIST’s other- 
activities related to safeguarding information and 
protecting privacy in networks. 

Regarding NIST’s computer-security budget, 
OTA did not determined the extent to which addi¬ 
tional funding is needed, or the extent to which 
additional funding would improve the overall ef¬ 
fectiveness of NIST’s information-security activi¬ 
ties. However, in staff discussions and workshops 
during the course of the assessment, OTA found 
that individuals from outside and within govern¬ 
ment repeatedly noted that NIST’s security activi¬ 
ties were not proactive and that NIST often lagged 
in providing useful and needed standards (the 
FIPS) and guidelines. Many individuals from the 
private sector felt that NIST’s limited resources 
for security activities precluded NIST from doing 
work that would also be useful to industry. Addi¬ 
tional resources, whether from overall increases in 
NIST’s budget or otherwise, could enhance 


11 Office of Management and Budget. "Security of Federal Automated Information,” Proposed Revision of OMB Circular No. A-130 Ap- 
pendix III (transmittal memorandum), At this writing, the proposed revision of Appendix III was available from NIST via World Wide Web at 
http://csrc.ncsl.nist.gov/secplcy as <al30app3.txt>. 
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NIST’s technical capabilities, enable it to be more 
proactive, and hence be more useful to federal 
agencies and to industry. 

OTA found that NIST activities with respect to 
standards and guidelines related to cryptography 
are a special case, however. Increased funding 
alone will not be sufficient to ensure NIST’s tech¬ 
nological leadership or its fulfillment of the “bal¬ 
ancing” role as envisioned by the Computer 
Security Act of 1987. With respect to cryptogra¬ 
phy, OTA concluded that national security 
constraints set forth in executive branch policy di¬ 
rectives appear to be binding. These constraints 
have resulted, for example, in the closed processes 
by which the Escrowed Encryption Standard 
(Clipper) was developed and implemented. In¬ 
creased funding could enable NIST to become a 
more equal partner to NSA, at least in deploying 
(if not developing) cryptographic standards. But, 
if NIST/NSA processes and outcomes are to re¬ 
flect a different balance of national security and 
other public interests, or more openness, than has 
been evidenced over the past five years, OTA con¬ 
cluded that clear policy guidance and oversight 
(not just funding) will be needed. 

LEGAL ISSUES AND 
INFORMATION SECURITY 

The laws currently governing commercial trans¬ 
actions, data privacy, and intellectual property 
were largely 7 developed for a time when tele¬ 
graphs, typewriters, and mimeographs were the 
commonly used office technologies and business 
was conducted with paper documents sent by 
mail. Technologies and business practices have 
dramatically changed, but the law has been slower 
to adapt. Computers, electronic networks, and in¬ 
formation systems are now used to routinely proc¬ 
ess, store, and transmit digital data in most 
commercial fields. OTA found that changes in 
communication and information technologies 
were particularly significant in three areas: elec¬ 


tronic commerce, privacy and transborder data 
flow, and digital libraries. 

I Electronic Commerce 

As businesses replace conventional paper docu¬ 
ments with standardized computer forms, the 
need arises to secure the transactions and establish 
means to authenticate and provide nonrepudiation 
sendees for electronic transactions, that is, a 
means to establish authenticity and certify that the 
transaction was made. Absent a signed paper doc¬ 
ument on which any nonauthorized changes could 
be detected, a digital signature to prevent, avoid, 
or minimize the chance that the electronic docu¬ 
ment has been altered must be developed. In con¬ 
trast to the courts’ treatment of conventional, 
paper-based transactions and records, little guid¬ 
ance is offered as to whether a particular safeguard 
technique, procedure, or practice will provide the 
requisite assurance of enforceability in electronic 
form. This lack of guidance concerning security 
and enforceability is reflected in the diversity of 
security and authentication practices used by 
those involved in electronic commerce. 

Legal standards for electronic commercial trans¬ 
actions and digital signatures have not been fully 
developed, and these issues have undergone little 
review in the courts. Therefore, OTA noted that 
immediate action by Congress might not be war¬ 
ranted. 12 However, OTA noted the need for con¬ 
gressional awareness of these issues: 

OPTION: Congress could monitor the issue of 
legal standards for electronic transactions and 
digital signatures, so that these are considered in 
future policy decisions about information secu¬ 
rity. 

Such attention would be especially timely, given 
the increasing focus of the national and interna¬ 
tional legal communities and the states on devel¬ 
oping legal standards for electronic commerce, as 
well as guidelines and model legislation for digi¬ 
tal signatures. 


12 Note this refers to legal standards for contracts, rules of evidence, and so forth, not to specific technical standards like the DSS. 
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For example, the American Bar Association’s 
(ABA) Information Security Committee, Science 
and Technology Section, is drafting “Global Digi¬ 
tal Signature Guidelines and model legislation. 
The ABA effort includes federal-agency represen¬ 
tatives, as well as representatives from the private 
sector and other governments. With participation 
by the International Chamber of Commerce and 
the U.S. State Department, the United Nations 
Commission on International Trade Law has com¬ 
pleted a Model Law on electronic data interchange 
(EDI). 13 

Utah has just enacted digital signature legisla¬ 
tion. The Utah Digital Signature Act 14 is intended 
to provide a reliable means for signing computer- 
based documents and to provide legal recognition 
of digital signatures using “strong authentication 
techniques” based on asymmetric cryptography. 
To assure a minimum level of reliability in digital 
signatures, the Utah statute provides for the li¬ 
censing and regulation of certification authorities 
by a “Digital Signature Agency” (e.g., the Divi¬ 
sion of Corporations and Commercial Code of the 
Utah Department of Commerce). The act, first 
drafted as a proposed model law, provides that the 
private key is the property of the subscriber who 
rightfully holds it (and who has a duty to keep it 
confidential); thus, tort or criminal actions are 
possible for theft or misuse. It is technology-inde¬ 
pendent; that is, it does not mandate use of a spe¬ 
cific signature technique, although it envisions 
use of signatures based on standards similar to or 


including the ANSI X.9.30 or ITU X.509 stan¬ 
dards. 15 (Also see discussion in chapter 4 of this 
background paper.) 

Liability issues are also important to the devel¬ 
opment of electronic commerce and the underpin¬ 
ning institutional infrastructures, including (but 
not limited to) escrow agents for key-escrowed 
encryption systems and certificate authorities for 
public-key infrastructures. Widespread use of cer¬ 
tificate-based, public-key infrastructures will re¬ 
quire resolution and harmonization of liability 
requirements for trusted entities, whether these be 
federal certificate authorities, private certificate 
(or “certification”) authorities, escrow agents, 
banks, clearinghouses, value-added networks, or 
other entities. 16 

I Protection of Privacy in Data 

Since the 1970s, the United States has concen¬ 
trated its efforts to protect the privacy of personal 
data collected and archived by the federal govern¬ 
ment. Rapid development of networks and in¬ 
formation processing by computer now makes it 
possible for large quantities of personal informa¬ 
tion to be acquired, exchanged, stored, and 
matched very quickly. As a result, a market for 
computer-matched personal data has expanded 
rapidly, and a private sector information industry 
has grown around the demand for such data. 

OTA found that increased computerization and 
linkage of information maintained by the federal 


13 Information on ABA and United Nations activities provided by Michael Baum, Principal, Independent Monitoring, personal commu- 
nication, Mar. 19,1995. See also Michael S. Baum, Federal Certification Authority Liability and Policy: Law and Policy of Certificate-Based 
Public Key and Digital Signatures, NIST-GCR-94-654, NTIS Doc. No. PB94-191-202 (Springfield, VA: National Technical Information Ser¬ 
vice, 1994). 

14 Utah Digital Signature Legislative Facilitation Committee, “Utah Digital Signature Legislation,” Dec. 21,1994. The Utah Digital Signa¬ 
ture Act act was signed into law on Mar. 10, 1995, as section 46-3-101 et seq., Utah Code Annotated . (Prof. Lee Hollaar, University of Utah, 
personal communication. Mar. 22, 1995.) 

15 Utah Digital Signature Act, ibid. The model legislation was endorsed by the American Bar Association, Information Security Committee 
of the Science and Technology Section, EDI/Information Technology Division; Prof. Lee Hollaar, University of Utah; Salt Lake Legal Defend¬ 
ers Assoc.; Statewide Association of Public Attorneys; Utah Attorney General’s Office; Utah Dept, of Corrections; Utah Information Technolo¬ 
gy Commission; Utah Judicial Council; and Utah State Tax Commission. 

16 See Michael Baum, op. cit., footnote 12 for discussion of liability exposure, legal considerations, tort and contract remedies, government 
consent to be liable, and recommendations and approaches to mitigate liability. 
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government is arguably not addressed by the Pri¬ 
vacy Act, which approaches privacy issues on an 
agency-by-agency basis. To address these devel¬ 
opments, OTA noted several alternatives: 

OPTION: Congress could allow each agency to 
address privacy concerns individually, through its 
present system of review boards. 

OPTION: Congress could require agencies to 
improve the existing data integrity boards, with a 
charter to make clearer policy decisions about 
sharing information and maintaining its integrity. 

OPTION: Congress could amend the existing 
law to include provisions addressing the sharing 
and matching of data, or restructure the law over¬ 
all to track the flow of information between insti¬ 
tutions. 

OPTION: Congress could provide for public ac¬ 
cess for individuals to information about them¬ 
selves, and protocols for amendment and 
correction of personal information. It could also 
consider providing for online publication of the 
Federal Register to improve public notice about 
information collection and practices. 

OTA noted that, in deciding between courses of 
actions, Congress could exercise its responsibility 
for oversight through heal ings and/or investiga¬ 
tions, gathering information from agency officials 
involved in privacy issues, as well as citizens, in 
order to gain a better understanding of what kinds 
of actions are required to implement better custo¬ 
dianship, a minimum standard of quality for pri¬ 
vacy protection, and notice to individuals about 
use and handling of information. 

Although the United States does not comprehen¬ 
sively regulate the creation and use of such data in 
the private sector, foreign governments (particu¬ 
larly the European Union) do impose controls. 
The Organization for Economic Cooperation and 
Development (OECD) adopted guidelines in 
1980 to protect the privacy and transborder flows 
of personal data. The difference between the level 
of personal privacy protection in the United States 
and that of its trading partners, who in general 
more rigorously protect privacy, could inhibit the 
exchange of data with these countries. U.S. busi¬ 
ness has some serious concerns about the Euro¬ 
pean Union (EU) proposal, as it relates to the data 


subject’s consent and the transfer of data to non- 
EU countries. OTA noted that Congress had a 
choice when addressing the sufficiency of existing 
U.S. legal standards for privacy and security in a 
networked environment for the private sector: 

OPTION: Congress could legislate to set stan¬ 
dards similar to the OECD guidelines; 

or, 

OPTION: Congress could allow individual in¬ 
terests, such as the business community, to advise 
the international community on its own of its in¬ 
terests in data protection policy. However, be¬ 
cause the EU’s protection scheme could affect 
U.S. trade in sendees and could impact upon indi¬ 
viduals, Congress may also wish to monitor and 
consider the requirements of foreign data protec¬ 
tion rules as they shape U.S. security and privacy 
policy to assure that all interests are reflected. 

OTA noted that a diversity of interests must be 
reflected in addressing the problem of maintain¬ 
ing privacy in computerized information— 
whether in the public or private sector. To deal 
with this, OTA noted that: 

OPTION: Congress could establish a Federal 
Privacy Commission. 

Proposals for such a commission or board were 
previously discussed by OTA in its 1986 report 
Electronic Record Systems and Individual Priva¬ 
cy. In that study, OTA cited the lack of a federal fo¬ 
rum in which the conflicting values at stake in the 
development of federal electronic systems could 
be fully debated and resolved. As privacy ques¬ 
tions will arise in the domestic arena, as well as in¬ 
ternationally, a commission could deal with these 
as well. 

I Protection of Intellectual Property in the 
Administration of Digital Libraries 

OTA found that the availability of protected intel¬ 
lectual property in digital libraries and other net¬ 
worked information collections is straining the 
traditional methods of protection and payment for 
use of intellectual property. Technologies (like 
digital signatures and encryption) developed for 
safeguarding information might also hold prom¬ 
ise for monitoring the use of copyrighted informa- 
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tion and facilitating means for collecting royalties 
and compensating the copyright holders. The ap¬ 
plication of intellectual-property law to protect 
works maintained in digital libraries continues to 
be problematic; traditional copyright concepts 
such as fair use are not clearly defined as they ap¬ 
ply to these works; and the means to monitor com¬ 
pliance with copyright law and to distribute 
royalties is not yet resolved. 

OTA had addressed these legal and institutional 
issues in an earlier report. Finding a Balance: 
Computer Software, Intellectual Property, and the 
Challenge of Technological Change. The 1992 re¬ 
port included several options to deal with the use 
of works in electronic form. 

During the 1994 assessment, OTA found that the 
widespread development of multimedia authoring 
tools—integrating film clips, images, music, 
sound, and other content—raises additional issues 
pertaining to copyright and royalties. With respect 
to copyright for multimedia works, OTA noted 
that: 

OPTION: Congress could allow the courts to 
continue to define the law of copyright as it is ap¬ 
plied in the world of electronic information; 

or, 

OPTION: Congress could take specific legisla¬ 
tive action to clarify and further define the copy¬ 
right law in the world of electronic information. 

Instead of waiting for legal precedents to be es¬ 
tablished or developing new legislation, OTA 


noted that Congress might try a third approach 
that would allow producer and user communities 
to establish common guidelines for use of copy¬ 
righted, multimedia works: 

OPTION: Congress could allow information 
providers and purchasers to enter into agreements 
that would establish community guidelines with¬ 
out having the force of law. In so doing, Congress 
could decide at some point in the future to review> 
the success of such an approach. 

More generally, with respect to private sector 
solutions for problems concerning rights and roy¬ 
alties for copyrighted works in electronic form, 
OTA noted that: 

OPTION: Congress could encourage private ef¬ 
forts to form rights-clearing and royalty-collec¬ 
tion agencies for groups of copyright owners. 

Alternatively, 

OPTION: Congress might allow> private sector- 
development of network tracking and mon itoring 
capabilities to support a fee-for-use basis for- 
copyrighted works in electronic form. 

In the latter case, Congress might wish to review 
whether a fee-for-use basis for copyrighted works 
in electronic form is workable, from the stand¬ 
point of both copyright law and technological ca¬ 
pabilities. OTA suggested that this might be 
accomplished by conducting oversight healings, 
undertaking a staff analysis, and/or requesting a 
study from the Copyright Office. 
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